blog

La comunicación sobre un WebSocket es full-duplex, cualquiera de los lados puede iniciar una transferencia de datos. La API WebSocket proporciona los métodos para el navegador reciba datos binarios o de texto.

En el siguiente fragmento de código, el objeto Blob está definido en la API de archivos. Contiene datos inmutables de bytes de propiedad Blob.size. Los datos son arbitrarios pero pueden ser descritos como un tipo MIME particular, con la propiedad Blob.type. Por ejemplo un Blob puede ser imágenes factibles de recuperar al desplazarse por una serie de fotos, transferencias de archivos para clientes de chat, o una plantilla jQuery para actualizar un nodo del DOM.

var ws = new WebSocket();
ws.onmessage = function(msg) {
if(msg.data instanceof Blob) { // alternativamente: ... instanceof
	ArrayBuffer
handleBinaryData(msg.data);
}
else {
handleStringData(msg.data);
}
}

El objeto ArrayBuffer está definido en la ECMAScript 2015 Language Specification. Contiene datos inmutables de bytes representando enteros con/sin signo, o valores de punto flotante de tamaño de bit variante (por ejemplo, entero de 8 bits, punto flotante de 64 bits).

Los datos para mensajes de cadenas siempre están codificados en UTF-8. El navegador debe hacer cumplir esta restricción, por ejemplo no deben aparecer bytes NULL dentro de la cadena.

Los datos son enviados utilizando el método de envío del objeto WebSocket. La API WebSocket pretende los datos ArrayBuffer, Blob y String sean argumentos aceptables para el envío. Sin embargo la compatibilidad con datos no String varía actualmente. Las cadenas de JavaScript son de manera nativa UTF-16; el navegador las codifica hacia UTF-8 para su transferencia.

Anotación: Encriptar siempre las conexiones WebSocket utilizando el esquema wss: //. La naturaleza persistente de las conexiones WebSocket, combinada con su mínima sobrecarga, anula la mayoría de las objeciones relacionadas con el rendimiento para implementar TLS en todas las conexiones.

Fuentes:

https://www.w3.org/TR/FileAPI/
https://262.ecma-international.org/6.0/#sec-typedarray-objects

Uno de los obstáculos para crear aplicaciones web manejando contenidos cambiando rápidamente (pensar en actualizaciones de estado y mensajes de chat), es el modelo de petición/respuesta HTTP. En la carrera por las micro-optimizaciones sobre este tipo de comportamiento, los sitios acaban chocando contra una pared en el cual el navegador debe sondear continuamente al servidor por actualizaciones. En otras palabras, el navegador siempre inicia la petición, ya sea GET, POST o algún otro método. Los WebSockets abordan esta limitación en el diseño de HTTP proporcionando un canal de comunicación bidireccional, también conocido como full-duplex. Las conexiones URL de WebSocket utilizan los esquemas ws:// o wss://, este último para conexiones sobre SSL/TLS.

Una vez el navegador establece una conexión WebSocket hacia un servidor, tanto el servidor como el navegador pueden iniciar una transferencia de datos a través de la conexión. Antes de los WebSockets, el navegador malgastaba ciclos de CPU o ancho de banda para sondear periódicamente al servidor en busca de nuevos datos. Con WebSockets, los datos enviados desde el servidor activan un evento del navegador. Por ejemplo, en lugar de comprobar cada dos segundos si hay un nuevo mensaje de chat, el navegador puede utilizar un enfoque basado en eventos los cuales se activan cuando una conexión WebSocket entrega nuevos datos desde el servidor.

La siguiente captura de red muestra el handshake utilizado para establecer una conexión WebSocket desde el navegador hacia un servidor público en ws: //echo.websocket.xyz

GET /?encoding=text HTTP/1.1
Host: echo.websocket.xyz
Connection: keep-alive, Upgrade
Sec-WebSocket-Version: 13
Origin:http: //websocket.xyz
Sec-WebSocket-Key: ZIeebbKKfc4iCGg1RzyX2w==
Upgrade: websocket
HTTP/1.1 101 WebSocket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: YwDfcMHWrg7gr/aHOOil/tW+WHo=
Server: Kaazing Gateway
Date: Thu, 22 Mar 2012 02:45:32 GMT
Access-Control-Allow-Origin:http: //websocket.xyz
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type

El navegador envía un valor aleatorio de 16 bytes en Sec-WebSocket-Key. El valor está codificado en base64 para sea aceptable para HTTP. En el ejemplo anterior, la representación hexadecimal de la clave es 64879e6db28a7dce22086835473c97db. En la práctica sólo es necesario recordar la representación codificada en base64.

El navegador también debe enviar la cabecera Origin. Esta cabecera no es específica de los WebSockets. “Origin” indica el contexto de navegación en el cual se crea la conexión WebSockets. En el ejemplo anterior, el navegador visitó http: //websocket.xyz/ para cargar la demo. La conexión WebSockets se está realizando hacia un “Origin” diferente, ws: //echo.websocket.xyz/. Esta cabecera permite el navegador y el servidor se acuerden sobre cuales “Origins” pueden mezclarse cuando se conectan a través de WebSockets.

Sec-WebSocket-Version indica la versión de WebSockets a utilizar. El valor actual es 13. Anteriormente era el 8. Como ejercicio para seguridad, nunca está de más ver como responde un servidor a valores no utilizados (del 9 al 11), valores negativos (-1), valores más altos (sería el 14 en este caso), valores potenciales de desbordamiento de enteros (2 ^32 , 2 ^32 +1, 2 ^64 , 2 ^64 +1), etc. Haciendo esto se estaría probando el propio código del servidor web en lugar de la aplicación web.

El significado de las cabeceras de respuesta del servidor es el siguiente.

Sec-WebSocket-Accept es la respuesta del servidor hacia la cabecera del reto del navegador, Sec-WebSocket-Key. La respuesta reconoce el reto combinando Sec-WebSocket-Key con un GUID definido en el RFC 6455. Este acuse de recibo es verificado por el navegador. Si los valores de la clave/aceptación de ida y vuelta coinciden, se abre la conexión. Caso contrario el navegador rechazará la conexión. El siguiente ejemplo demuestra la verificación de la clave utilizando herramientas de línea de comandos disponibles en la mayoría de los sistemas tipo Linux. El hash SHA-1 de Sec-WebSocket-Key y GUID concatenados coincide con el hash codificado en Base64 de la cabecera Sec-WebSocket-Accept calculado por el servidor.

{Sec-WebSocket-Key}{WebSocketKeyGUID}
ZIeebbKKfc4iCGg1RzyX2w==258EAFA5-E914-47DA-95CA-C5AB0DC85B11

$ echo -n 'ZIeebbKKfc4iCGg1RzyX2w==258EAFA5-E914-47DA-95CA-C5AB0DC85B11' | shasum -
6300df70c1d6ae0ee0aff68738e8a5fed5be587a -

$ echo -n 'YwDfcMHWrg7gr/aHOOil/tW+WHo=' | base64 -D | xxd
0000000: 6300 df70 c1d6 ae0e e0af f687 38e8 a5fe c..p........8...
0000010: d5be 587a

Este handshake de reto/respuesta está diseñado para crear una conexión única e impredecible entre el navegador y el servidor. Podrían surgir varios problemas si las claves de desafío fueran secuenciales, por ejemplo, 1 para la primera conexión, luego 2 para la segunda; o basadas en el tiempo, por ejemplo, “epoch time” en milisegundos. Una posibilidad son las condiciones de carrera; el navegador debería asegurarse de la clave de reto 1 no sea utilizada por dos solicitudes intentendo establecer una conexión al mismo tiempo. Otra preocupación es evitar las conexiones WebSockets se utilicen para ataques cruzados de protocolo.

Los ataques cruzado de protocolo son un viejo truco en el cual el tráfico de un protocolo se dirige hacia el servicio de otro protocolo con el fin de falsificar los comandos. Esto es lo más fácil de explotar con protocolos basados en texto. Por ejemplo recordar la primera línea de una petición HTTP el cual contiene un método, un URI y un indicador de versión:

GEThttp: //web.site/HTTP/1.0

El correo electrónico utiliza otro protocolo basado en texto, SMTP. Imaginar un navegador web con un objeto XMLHttpRequest (XHR), el cual no impone ninguna restricción sobre el método HTTP o el destino. Un spammer inteligente podría tratar de atraer a los navegadores hacia una página web el cual utiliza un objeto XHR para conectarse hacia un servidor de correo intentando una conexión como:

EHLOhttps: //correo.server:587 HTTP/1.0

O si se pudiera dar al XHR un método completamente arbitrario, un ciberatacante trataría de meter en este una orden de entrega de correo electrónico completa. El resto de la petición, incluyendo las cabeceras añadidas por el navegador, no importarían para el ataque:

EHLO%20correo.server:587%0a%0dMAIL%20FROM:<alice @social.
red>%0a%0dRCPT%20TO:<bob @social.red>%0a%0dDATAspamspamsp
am%0a%0d.%0ahttps: //correo.server:587 HTTP/1.1
Host: correo.server

La sintaxis no siempre es 100% correcta para los ataques entre protocolos; sin embargo, este tipo de ataques surgen debido a errores en la implementación (el navegador permite conexiones hacia puertos TCP con protocolos no HTTP ampliamente establecidos como el 25 o el 587, el navegador permite el objeto XHR envíe contenido arbitrario, el servidor de correo no aplica estrictamente la sintaxis).

Los WebSockets son más versátiles comparados con el objeto XHR. Al ser un protocolo orientado a mensajes puede transferir contenido binario o de texto, son un candidato principal para intentar ataques entre protocolos contra cualquier cosa, desde servidores SMTP hasta incluso protocolos binarios como SSH. El reto/respuesta Sec-WebSocket-Key y Sec-WebSocket-Accept garantiza un navegador adecuado se conecte hacia un servidor WebSocket válido en lugar de a cualquier tipo de servicio (por ejemplo, SMTP). La intención es evitar los ciberatacantes puedan crear páginas web provocando el navegador de la víctima envíe spam o realice alguna otra acción contra un servicio el cual no sea WebSocket; así como evitar que ataques como la inyección HTML entreguen cargas útiles los cuales puedan convertir una vulnerabilidad de Twitter en un generador de spam de gran volumen. El reto/respuesta evita el navegador sea utilizado como relevo para ataques contra otros servicios.

La cabecera Sec-WebSocket-Protocol (no presente en el ejemplo) proporciona a los navegadores información explícita sobre el tipo de datos a canalizar a través de un WebSocket.

Será una lista de protocolos separada por comas. Esto le da al navegador la oportunidad de aplicar decisiones de seguridad para protocolos comunes, en lugar de tratar con un flujo de datos opaco con implicaciones desconocidas para la configuración de seguridad o privacidad del usuario. Los marcos de datos pueden ser enmascarados con una operación XOR utilizando un valor aleatorio de 32 bits elegido por el navegador. Los datos se enmascaran para evitar modificaciones involuntarias por parte de dispositivos intermediarios como los proxies. Por ejemplo un proxy caché podría devolver incorrectamente datos antiguos para una solicitud, o un proxy el funcione mal podría manipular una trama de datos. Observar la especificación no utiliza el término encriptación, pues ese no es el propósito ni el efecto del enmascaramiento. La clave de enmascaramiento está incrustada dentro de la trama de datos si afecta - abre para que cualquier intermediario lo vea. Las conexiones TLS proporcionan encriptación con cifrados de flujo como RC4 o AES en modo CTR. Utilizar wss: // para conseguir un cifrado fuerte para la conexión WebSocket. De la misma manera se confiaría en https: // para los enlaces a las páginas de acceso o, preferiblemente, toda la aplicación.

Fuentes:

https://developer.mozilla.org/en-US/docs/Web/API/WebSocket
https://www.rfc-editor.org/rfc/rfc6455

Algunas características de HTML5 reflejan la experiencia real de los desarrolladores web, quienes han estado ampliando los límites de las capacidades del navegador para crear aplicaciones las cuales se vean, sientan, y funcionen igual a las aplicaciones "nativas" instaladas en el sistema del usuario. Uno de esos límites en los cuales se enfatiza es la venerable política del mismo origen, uno de los pocos mecanismos de seguridad presentes en los primeros navegadores. Los desarrolladores frecuentemente tienen razones legítimas para relajar la Política de Mismo Origen, ya sea para permitir un sitio se extienda a través de nombres de dominio específicos, o para hacer posible una interacción útil de sitios sobre dominios no relacionados. CORS permite a los desarrolladores de sitios otorgar permiso para un origen pueda acceder al contenido de los recursos cargados desde un origen diferente. (El comportamiento predeterminado del navegador permite solicitar recursos de diferentes orígenes, pero el acceso al contenido de cada recurso de respuesta está aislado por origen. Un sitio no puede asomarse al DOM de otro, por ejemplo, establecer cookies, leer nodos de texto conteniendo nombres de usuario, inyectar nodos JavaScript, etc.)

Uno de los caballos de batalla del navegador para producir peticiones es el objeto XMLHttpRequest (XHR). Dos de sus principales características, la capacidad de realizar peticiones asíncronas en segundo plano, y la capacidad de utilizar métodos no GET, lo convierten en un componente clave para los exploits. Como consecuencia, los navegadores han limitado cada vez más las capacidades de XHR para reducir su exposición adversa a la seguridad. Con CORS, los desarrolladores web pueden ampliar esos límites sin poner indebidamente en riesgo a los navegadores.

Los límites de seguridad en los recursos de origen cruzado se establecen mediante cabeceras de petición y respuesta. El navegador tiene tres cabeceras de petición:

Origin: El esquema/host/puerto del recurso iniciando la petición. El compartir debe ser otorgado para este Origen por el servidor. La seguridad asociada a esta cabecera se basa en provenir desde un navegador no comprometido. Su valor debe ser establecido con precisión por el navegador; no debe ser modificado por HTML, JavaScript o plugins.

Access-Control-Request-Method: Se utiliza en una petición de verificación previa para determinar si el servidor respetará el método o métodos requeridos de utilizar por el objeto XHR. Por ejemplo, es posible un navegador sólo necesite confiar en GET para una aplicación web, pero requiera un rango de métodos para un sitio web REST-ful. Por lo tanto, un sitio web puede imponer al navegador un concepto de "mínimos privilegios", por el cual sólo honra aquellos métodos considerados necesarios.

Access-Control-Request-Headers: Se utiliza en una petición de verificación previa para determinar si el servidor honrará las cabeceras adicionales requeridos de establecer por el objeto XHR. Por ejemplo, JavaScript para el lado del cliente tiene prohibido manipular la cabecera Origin. Por otro lado, el objeto XHR puede requerir subir archivos a través de un método POST, en cuyo caso puede ser deseable establecer una cabecera Content-Type (aunque los navegadores limitarán los valores pudiendo contener esta cabecera).

El servidor tiene cinco cabeceras de respuesta instruyendo al navegador sobre aquello lo cual debe permitir en términos de compartir el acceso hacia los datos de una respuesta hacia una petición de origen cruzado:

Access-Control-Allow-Credentials Puede ser "true" (verdadero) o "false" (falso). Por defecto el navegador no enviará cookies, cadenas de autenticación HTTP (por ejemplo, Basic, Digest, NTLM), o certificados SSL de cliente a través de los orígenes. Esta restricción evita el contenido malicioso intente filtrar las credenciales hacia un origen no aprobado. Si se establece este encabezado como verdadero, cualquier dato de esta categoría de credenciales se puede compartir entre orígenes.

Access-Control-Allow-Headers Las cabeceras pueden incluir una petición. Existen cabeceras inmutables, como Host y Origin. Esto se aplica a cabeceras como
Content-Type, así como a las X-headers personalizadas

Access-Control-Allow-Methods Los métodos factible de ser utilizados por una solicitud para obtener el recurso. Siempre es preferible limitar los métodos a los cuales se consideren necesarios, lo cual es usualmente sólo GET.

Access-Control-Allow-Origin El origen u orígenes con los cuales el servidor permite al navegador compartir los datos de respuesta del servidor. Puede ser un origen explícito (por ejemplo, http: //otro.site), * (por ejemplo un comodín para coincidir con cualquier origen, o "null" (para negar solicitudes). El comodín ( * ) siempre impide las credenciales se incluyan en una solicitud de origen cruzado, independientemente de la cabecera Access-Control-Allow-Credentials.

Access-Control-Expose-Headers Una lista de cabeceras factible de hacer visibles por el navegador para el cliente. Por ejemplo JavaScript podría leer las cabeceras expuestas de una respuesta XHR.

Access-Control-Max-Age La duración en segundos durante el cual se puede almacenar en caché la respuesta para una solicitud de verificación previa. Los tiempos más cortos incurren en una mayor sobrecarga, pues el navegador se ve forzado a renovar sus permisos CORS con una nueva petición de verificación previa. Los tiempos más largos aumentan la exposición potencial de los controles excesivamente permisivos desde una solicitud de verificación previa. Esta es una decisión política para los desarrolladores web. Una buena referencia para este valor sería la cantidad de tiempo una aplicación web mantiene la sesión de un usuario sin requerir la reautenticación, como un botón "Recuérdame" común entre los sitios. Así las duraciones típicas pueden ser de unos minutos, un día laborable o dos semanas, con preferencia por tiempos más cortos.

Compartir recursos entre orígenes debe ser permitida por el sitio web. El acceso a los datos de respuesta ante peticiones GET y POST usuales, estará siempre restringido al mismo origen, a menos la respuesta contenga una de las cabeceras relacionadas con CORS. Un servidor puede responder a estos tipos de peticiones "usuales" con cabeceras para control de acceso. En otras situaciones el navegador puede utilizar primero una petición previa para establecer una política CORS. Esto es más común cuando se utiliza el objeto XHR.

En este ejemplo, suponer el HTML se carga desde un Origen de http: //web.site. El siguiente JavaScript muestra una petición XHR realizado con un método PUT hacia otro Origen (http ://friendly.app) el cual requiere incluir credenciales (el valor "true" para el tercer argumento de la función xhr.open()):

var xhr = new XMLHttpRequest();
xhr.open("PUT", "http: //friendly.app/other_origin.html", true);
xhr.send();

Una vez se procesa xhr.send(), el navegador inicia una petición de verificación previa para determinar si el servidor está dispuesto a compartir un recurso de su propio origen http: //friendly.app con el origen http: //web.site del recurso solicitante. La petición se parece a lo siguiente

OPTIONS http ://friendly.app/other_origin.html HTTP/1.1
Host: friendly.app
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Origin: http: //web.site
Access-Control-Request-Method: PUT

Si el servidor de friendly.app desea compartir recursos con http: //web.site, entonces responderá con algo como:

HTTP/1.1 200 OK
Date: Tue, 03 Apr 2022 06:51:53 GMT
Server: Apache
Access-Control-Allow-Origin: http: //web.site
Access-Control-Allow-Methods: PUT
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 10
Content-Length: 0

Este intercambio de cabeceras indica al navegador exponga el contenido de las respuestas del origen http: //friendly.app con los recursos cargados desde el origen http: //web.site. Así un objeto XHR podría recibir datos JSON de friendly.app factibles de ser leídos, manipulados y mostrados por web.site.

CORS es un acuerdo entre orígenes el cual instruye al navegador relajar la Política de Mismo Origen, lo cual de otra manera impediría los datos de respuesta de un origen estuviesen disponibles para los recursos del lado del cliente de otro origen. Permitir CORS acarrea implicaciones de seguridad para una aplicación web. Por lo tanto, es importante tener en consideración los principios sobre la Política de Mismo Origen cuando se relaja intencionalmente:

• Asegúrese de el código del servidor siempre verifica las cabeceras Origin y Host coinciden, y el Origen coincide con una lista de valores permitidos antes de responder con cabeceras CORS. Seguir el principio de "fallo seguro": cualquier error debería devolver una respuesta vacía o una respuesta con el mínimo contenido.
• Recordar CORS establece el compartir por origen, no por recurso. Si sólo es necesario compartir un único recurso, considerar la posibilidad de mover ese recurso hacia su propio subdominio en lugar de exponer el resto de los recursos de la aplicación web. Por ejemplo, establecer un origen separado para el acceso hacia la API en lugar de exponer la API a través de un directorio en el origen principal del sitio.
• Utilizar un valor comodín ( * ) para el encabezado Access-Control-Allow-Origin con moderación. Este valor expone los datos del recurso (por ejemplo la página web) hacia las páginas de cualquier sitio web. Recordar la política de mismo origen no impide una página cargue recursos desde orígenes no relacionados, sino previene la página lea los datos de respuesta de esos orígenes.
• Evalúe el impacto añadido para los ataques de inyección HTML (cross-site scripting). Una inyección de HTML exitosa será capaz de ejecutarse dentro del origen del sitio víctima. Cualquier relación de confianza establecida con CORS estará adicionalmente expuesta al exploit.

CORS es una de las características de HTML5 el cual tiene uso como utilidad para los exploits web. Esto no significa CORS sea fundamentalmente defectuoso o inseguro. Significa los ciberatacantes seguirán exfiltrando datos del navegador, escaneando redes en busca de hosts vivos o puertos abiertos, e inyectando JavaScript utilizando nuevas tecnologías. Las aplicaciones web no serán menos seguras, los exploits serán más sofisticados.

Fuentes:

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
https://en.wikipedia.org/wiki/Cross-origin_resource_sharing

HTML DOM es un modelo de objetos para HTML. El cual define; elementos HTML como objetos, propiedades para todos los elementos HTML, métodos para todos los elementos HTML, y eventos para todos los elementos HTML. También HTML DOM es un API (Interfaz de programación) para JavaScript.

Esta simple declaración <!doctype html> permite una página web sea oficialmente HTML5. W3C proporciona un documento el cual describe grandes diferencias entre HTML5 y HTML4. La siguiente lista destaca los cambios interesantes:

• <!doctype html> es todo lo necesario. Los navegadores modernos toman esto como una instrucción para adoptar un modo estándar para interpretar HTML. Atrás quedaron los días de las discusiones de HTML vs. XHTML y de añadir DTDs hacia la declaración doctype.
• UTF-8 se convierte en la codificación preferida. Esta codificación es la más amigable con el transporte HTTP, mientras se es capaz de mantener la compatibilidad con la mayoría de las representaciones lingüísticas. Aquí se debe estar atento a los errores de seguridad debidos a las conversiones de caracteres hacia y desde UTF-8.
• Interpretación HTML tiene reglas explícitas. Se acabó la dependencia sobre las peculiaridades de la implementación de un navegador, o el verse frustrado por estas. Los caprichos conducen a la ambigüedad, lo cual conduce hacia la inseguridad. Las instrucciones claras sobre el manejo de caracteres no válidos (como los bytes NULL) o etiquetas no terminadas reducen las probabilidades de un navegador "arregle" el HTML hasta el punto de una vulnerabilidad de inyección de HTML sea fácilmente explotable.
• Nuevas etiquetas y atributos son la perdición para los filtros de seguridad basadas en listas negras. Toda esta cuidadosa atención a cada una de las etiquetas enumeradas en la especificación HTML4 deben actualizarse con HTML5.
• El aumento en la complejidad implica una disminución en la seguridad; es más difícil detectar los casos de esquina y situaciones patológicas exponiendo vulnerabilidades.
• Nuevas API para todo, desde elementos multimedia hasta la conversión hacia base64 para el registro de manejadores de protocolo personalizados. Esto muestra la complejidad en la implementación la cual puede introducir errores en el navegador.

Fuentes:

https://www.w3schools.com/whatis/whatis_htmldom.asp
https://www.w3.org/TR/html5-diff/
https://dom.spec.whatwg.org/

Para comprender el funcionamiento y las características del malware, además de evaluar su impacto en el sistema, frecuentemente se utilizan diferentes técnicas para análisis. A continuación se presenta una clasificación para estas técnicas de análisis:

Análisis Estático

Es el proceso de analizar un binario sin ejecutarlo. Es el más fácil de realizar, además de permitir extraer los metadatos asociados al binario sospechoso. El análisis estático puede no revelar toda la información requerida, pero algunas veces puede proporcionar información interesante la cual ayude a determinar donde enfocar los esfuerzos posteriores de análisis.

Análisis Dinámico (Análisis de comportamiento):

Es el proceso de ejecutar el binario sospechoso en un entorno aislado para vigilar su comportamiento. Esta técnica de análisis es fácil de realizar, además de proporcionar información valiosa sobre la actividad del binario durante su ejecución. Esta técnica de análisis es útil, pero no revela todas las funcionalidades del programa hostil.

Análisis de Código

Es una técnica avanzada la cual se centra en el análisis del código, con el propósito de comprender el funcionamiento interno del binario. Esta técnica revela información la cual no es posible determinar solo desde el análisis estático y dinámico. El análisis de código se divide a su vez en análisis estático de código y análisis dinámico de código. El análisis estático de código implica desensamblar el binario sospechoso, y observar su código para entender el comportamiento del programa, mientras el análisis dinámico de código implica depurar el binario sospechoso de forma controlada para entender su funcionalidad. El análisis de código requiere conocimientos sobre lenguajes de programación, además de conceptos sobre sistemas operativos.

Análisis de Memoria (Forense de Memoria)

Esta es una técnica de análisis para la memoria RAM de la computadora, con el propósito de buscar artefactos forenses. Es típicamente una técnica forense, pero su integración en el análisis de malware ayudará a comprender el comportamiento del mismo después de la infección. El análisis de la memoria es especialmente útil para determinar las capacidades de ocultación y evasión del malware.

Nota: Integrar diferentes técnicas de análisis mientras se realiza un análisis de malware, puede revelar mucho información contextual, la cual podría ser valiosa en la investigación del malware

Fuentes:

https://www.crowdstrike.com/cybersecurity-101/malware/malware-analysis/
https://zeltser.com/malware-analysis-cheat-sheet/
https://forensicswiki.xyz/wiki/index.php?title=Memory_analysis

El análisis de malware es el estudio del comportamiento del malware. El objetivo del análisis de malware es comprender el funcionamiento del malware, además de como detectarlo y eliminarlo. Involucra analizar el binario sospechoso en un entorno seguro para identificar sus características y funcionalidades, de manera se puedan construir mejores defensas para proteger la red de una organización.

El principal motivo para realizar análisis de malware es para extraer información desde la muestra de malware, lo cual puede ayudar a responder ante un incidente de malware. La meta del análisis de malware es determinar la capacidad del malware, detectarlo, y contenerlo. También ayuda a determinar patrones identificables los cuales pueden ser utilizados para curar y prevenir futuras infecciones. Las siguientes son algunas de las razones por las cuales se realiza un análisis de malware:

• Para determinar la naturaleza y el propósito del malware. Por ejemplo, puede ayudar a determinar si el malware es roba información, es un bot HTTP, un bot de spam, un rootkit, un keylogger o un RAT, etc.
• Para comprender cómo se comprometió el sistema y su impacto
• Para identificar los indicadores de red asociados al malware, los cuales pueden luego utilizarse para detectar infecciones similares utilizando la vigilancia de la red. Por ejemplo, durante el análisis, si se determina un malware se contacta con un dominio/dirección IP particular, se puede utilizar este dominio/dirección IP para crear una firma y supervisar el tráfico de red, para identificar todos los hosts contactándose con ese dominio/dirección IP
• Para extraer indicadores basados en el host, como nombres de archivos y llaves de registro, lo cual a su vez, pueden utilizarse para determinar una infección similar mediante vigilancia basada en host. Por ejemplo, si se conoce un malware crea una llave del registro, se puede utilizar esta llave del registro como indicador para crear una firma, o escanear la red para identificar los hosts teniendo la misma llave del registro
• Determinar la intención y el motivación del atacante. Por ejemplo, durante el análisis, si encuentra el malware está robando credenciales bancarias, entonces se puede deducir el motivo del atacante es la ganancia monetaria

Mencionar también, los equipos para inteligencia de amenazas frecuentemente utilizan indicadores determinados a partir de un análisis de malware, para clasificar el ataque y atribuirlo a amenazas conocidas. El análisis de malware puede ayudar a obtener información sobre quién podría estar detrás del ataque (competidor, grupo de ataque patrocinado por un estado, etc.).

Fuentes:

https://www.first.org/global/sigs/malware/ma-framework/#Why-Malware-Ana…
https://csrc.nist.gov/publications/detail/sp/800-83/rev-1/final

Malware es un código el cual realiza acciones maliciosas; puede tomar la forma de un ejecutable, un script, un código, o cualquier otro software. Los atacantes utilizan el malware para robar información sensible, espiar un sistema infectado o tomar el control del sistema. Típicamente se introduce en un sistema sin consentimiento, y puede ser entregado a través de diversos canales de comunicación, como el correo electrónico, la web o las unidades USB.

Las siguientes son algunas de las acciones maliciosas realizadas por malware:

• Interrumpir el funcionamiento de la computadora
• Robar información sensible, incluyendo datos personales, comerciales y financieros
• Acceso no autorizado al sistema de la víctima
• Espiar a las víctimas
• Envar mensajes de correo electrónico no deseados
• Realizar ataques para denegación de servicio distribuido (DDOS)
• Bloquear los archivos la computadora y pedir un rescate por estos

Malware es un término amplio el cual se refiere a diferentes tipos de programas maliciosos; como troyanos, virus, gusanos y rootkits. Al realizar un análisis de malware, frecuentemente se encontrará con varios tipos de programas maliciosos; algunos de estos programas maliciosos son categorizados en base a su funcionalidad y vectores de ataque, como los mencionados a continuación:

Virus o gusano: Malware capaz de copiarse a sí mismo y propagarse hacia otras computadoras. Un virus necesita la intervención del usuario, mientras un gusano puede propagarse sin la intervención del usuario.

Troyano: Malware el cual se disfraza como un programa normal para engañar a los usuarios lo instalen en sus sistemas. Una vez instalado, puede realizar acciones maliciosas como robar datos sensibles, subir archivos hacia el servidor del atacante, o vigilar las cámaras web.

Backdoor / Troyano de Acceso Remoto (RAT): Tipo de troyano el cual permite al atacante acceder y ejecutar comandos en el sistema comprometido.

Adware: Malware el cual presenta publicidad no deseada (anuncios) al usuario. Usualmente se entrega a través de descargas gratuitas, y pueden forzar a instalar software en el sistema.

Botnet: Se trata de un grupo de computadoras infectadas con el mismo malware (llamados bots), esperando recibir instrucciones del servidor de comando y control controlado por el atacante. El atacante puede luego entregar un comando hacia estos bots, lo cual puedenrealizar actividades maliciosas, como ataques DDoS o envío de mensjaes de correos electrónicos spam.

Robar de información: Malware diseñado para robar datos sensibles, como credenciales bancarias o pulsaciones de teclas desde sistema infectado. Algunos ejemplos de estos programas maliciosos incluyen key loggers, spyware, sniffers y form grabbers.

Ransomware: Malware el cual pide un rescate por el sistema, bloqueando a los usuarios el uso de sus computadoras o encriptando sus archivos.

Rootkit: Malware el cual proporciona al atacante acceso privilegiado hacia el sistema infectado, además oculta su presencia o la de otros programas.

Downloader o dropper: Malware diseñado para descargar o instalar componentes de malware adicionales.

Fuentes:

https://en.wikipedia.org/wiki/Malware
https://www.malwarebytes.com/glossary

Una de las principales distinciones operativas en la zona de Campo, en comparación con la zona Empresarial, son los estrictos requerimientos para la fiabilidad y seguridad, especialmente para el control de infraestructuras críticas. Por ejemplo los dispositivos de Campo en infraestructura críticas están diseñados como sistemas tolerantes a fallos y críticos en seguridad. Estos requisitos de seguridad y fiabilidad tienen un profundo impacto en múltiples aspectos de los ICSs, desde el diseño (ejemplo, sistemas redundantes) hasta el mantenimiento (ejemplo, actualizar y parchar). Por esto se tiene especial atención para describir requerimientos específicos, los cuales surgen como resultado de los requerimientos para seguridad y fiabilidad en los dispositivos y redes de campo.

Los sistemas de Campo en infraestructuras críticas son requeridos proporcionen muy altos niveles de disponibilidad, fiabilidad bajo demanda, y en algunos casos seguridad bajo un amplio rango de condiciones operacionales. Debido a las consecuencias potenciales de una falla en un sistema crítico, estos sistemas deben reducir la probabilidad de se produzcan incluso fallos de baja probabilidad. Los sistemas donde las consecuencias de una falla son elevadas deben ser sistemas fiables, los cuales tengan la capacidad de evitar fallas de servicios los cuales son más frecuentes y más severos de aquello aceptable para el usuario o usuarios, además de también tener la capacidad de entregar servicios los cuales sean justificablemente confiables. Los sistemas fiables frecuentemente utilizan una de las siguientes perspectivas para mejorar la fiabilidad y seguridad de los sistemas en la presencia de fallas.

• Evitar fallos: Evitar fallas mediante el diseño, por ejemplo construir el sistema correctamente desde el inicio
• Eliminación de fallos: Reducir por verificación y prueba la presencia de fallos
• Tolerancia a fallos: Proporcionar un funcionamiento correcto aunque existan fallos

La tolerancia a fallos es la única la cual se activa en la fase operacional. Por esto para las técnicas sobre tolerancia a fallos trabajen efectivamente, es importante entender los tipos de fallas los cuales pueden experimentar los sistemas. Tradicionalmente los métodos y técnicas para tolerancia a fallos se han sido utilizado para dos clases de fallas. La primera son fallas de hardware, las cuales podrían ser permanentes o transitorias por naturaleza. La segunda son fallas de software, las cuales se activan cuando se suscitan entradas inusuales o condiciones de estado. Tanto las técnicas para tolerancia de fallos en hardware y software utilizan redundancia para superar los efectos de las fallas.

Los métodos y técnicas para la tolerancia a fallos de hardware, utilizan técnicas como votación, códigos EDC, duplicación y comparación para detectar y corregir los efectos de las fallas. Estas técnicas funcionan para fallas de hardware porque se supone estos fallos se producen de manera aleatoria, independientemente de uno del otro. Los fallos en software usualmente no se producen de manera aleatoria o independiente el uno del otro, pues ocurren cuando condiciones de entrada/estado desencadenan una falla de software. Como tal, meramente la replicación y redundancia no funcionan.

Las técnicas para tolerancia a fallos de software, frecuentemente emplean una diversidad de técnicas y defensa en profundidad, para detectar y corregir fallas de software en tiempo de ejecución. Esto incluye: diversas formas de software ejecutándose sobre diferentes procesadores, programación de N versiones donde las diferentes versiones del programa son escritas por diversos equipos de programación, vigilancia en tiempo de ejecución donde una “vigilancia segura” verifica las salidas para ver si son razonables o una violación de las propiedades. En general los sistemas tolerantes a fallos se basan en diseños resistentes y en el conocimiento o vigilancia continua del estado. En estos sistemas las caracterísicas de autovigilancia y autoprueba son prominentes, como las pruebas cíclicas de hardware, análisis de temporización para detectar procesos colgados, temporizadores de vigilancia independientes, desconexión cableada en caso de falla, verificaciones para la integridad de datos, y en caso de falla, mensajes de falla y señales son utilizados por la detección de errores a nivel de aplicación, para reforzar la operación a prueba de fallo.

Otra característica importante de los sistemas fiables es ser frecuentemente en tiempo real. Un sistema en tiempo real se caracteriza por su continua interacción con su entorno, continuamente aceptando peticiones desde el entorno y continuamente produciendo reacciones. En los sistemas en tiempo real, la corrección o la seguridad del sistema reactivo está relacionado con su comportamiento en el tiempo mientras interactúa con su entorno. Así la corrección del resultado también depende de la puntualidad en la entrega.

Aunque los métodos para tolerancia a fallos en software y hardware son suficientes para los fallos aleatorios suscitándose o fallas de diseño, no son suficientes cuando las fallas son maliciosas e intencionales en naturaleza, como fallas causadas por ciberataques. En el contexto de CPSs, la verdadera resiliencia debe considerar aquello lo cual representa una operación adecuada de la aplicación del proceso, al frente de muchas condiciones adversas, incluidas aquellas atribuibles a las amenazas desde interacciones humanas no deseadas, como los ciberactores maliciosos. Las ciberfallas en CPSs caen en dos clases:

• Fallas no maliciosas: Introducidos sin propósitos maliciosos
• Fallas maliciosas o ciberataques: Introducidos durante ya sea el desarrollo del sistema, con la intención de causar daño al sistema durante su utilización, o directamente durante su uso

Mientras las fallas no maliciosas son mayormente introducidas por errores involuntarios y malas decisiones operacionales, las fallas maliciosas o ciberataques son introducidas por un adversario humano inteligente, o agente de amenaza con un propósito malicioso, para alterar el funcionamiento de un sistema. Por ejemplo un adversario podría lanzar un ataque externo en el cual un atacante intercepta mensajes, inyecta datos falsos, o niega acceso hacia ciertos módulos. Aunque estas acciones pueden ciertamente alterar la operación de un sistema, pueden ser detectadas y mitigadas con tecnologías actuales, como cortafuegos, encriptación, y autenticación. En otros casos un atacante podría comprometer y completamente controlar algunos componentes del sistema. En este escenario el atacante podría modificar o descartar mensajes críticos, inyectar información falsa de reporte o vigilancia, generar eventos falsos, deshabilitar medidas críticas de seguridad, coordinar ataques involucrando múltiples componentes, y mucho más.

Fuentes:

https://www.arcweb.com/events/videos-webcasts/safety-reliability-indust…
https://www.fortinet.com/resources/cyberglossary/ics-security

En general los ICSs pueden ser sistemas muy complejos. Pueden incluir miles de diferentes componentes distribuidos a través de regiones geográficas, además de controlar procesos complejos en tiempo real. La mayoría de las veces la gran escala de estos sistemas, como también la diversidad de dispositivos y requerimientos, requiere los sistemas ICSs sean segmentados en múltiples zonas operacionales. Cada zona operacional tiene características y requerimientos únicos. Para enfrentar esta complejidad, se han desarrollado diferentes modelos para representar sistemas ICS. Desde la perspectiva de la ciberseguridad, los sistemas ICS pueden ser ampliamente segmentados en tres diferentes zonas:

• Zona empresarial
• Zona de control
• Zona de campo

Tener esta segmentación es extremadamente útil para determinar controles relevantes en seguridad. El modelo de tres zonas ha sido utilizado, aunque diferentes nombres son frecuentemente utilizados para referirse a conceptos similares. Los componentes y características generales de cada zona se describen a continuación.

La zona empresarial incluye redes empresariales y sistemas de la empresa; incluye diversos dispositivos de punto final, los cuales evolucionan rápidamente, además son actualizados continuamente. Esta zona incluye redes empresariales comúnmente basadas sobre el protocolo IP, y muy frecuentemente conectadas hacia redes externas, además de Internet. Estas redes la mayoría de las veces se mantienen separadas de las redes operacionales utilizadas en otras zonas. La zona empresarial es muy similar a los entornos TI tradicionales encontrados fuera del ámbito de los ICSs. Por lo tanto muchas soluciones en ciberseguridad del mundo TI pueden ser directamente aplicadas.

La zona de control incluye elementos de control distribuido en sistemas SCADA. Estas zonas incluyen entornos de salas para control. La zona de control comparte algunas similitudes con la zona empresarial, tales como redes basadas en el protocolo IP. Los requerimientos en la zona de control, por lo tanto cambian drásticamente para enfatizar en la seguridad y fiabilidad. Los dispositivos en esta zona pueden no actualizarse tan frecuentemente, además las redes pueden estar sujetas a estrictas limitaciones de tiempo. Por lo tanto pocas soluciones en ciberseguridad del mundo TI pueden ser directamente utilizadas en esta zona.

La zona de campo, también conocida como zona de planta, procesos, u operaciones, incluye los dispositivos o redes a cargo del control y automatización. La zona de campo es aquella la cual hospeda los CPSs. Los dispositivos en esta zona frecuentemente incluyen dispositivos incorporados de propósito único, como los Controladores Lógicos Programables (PLC), los cuales tienen recursos computacionales limitados. Las redes de comunicación en esta zona son mucho más diversas, y van más allá de las redes IP, empleando una gran variedad de protocolos e interfaces físicas. Los dispositivos y redes en esta zona están sujetas a estrictos requerimientos en seguridad, fiabilidad, y temporización. . Por lo tanto las soluciones en ciberseguridad del mundo TI raramente o nunca se aplican aquí.

Este modelo de tres capas se debe admitir es excesivamente simplificado. Sin embargo es muy útil diferenciar los aspectos técnicos únicos conformando los requisitos de seguridad. Cada zona tiene diferentes requerimientos en seguridad, además es importante establecer limites fuertes y abstracciones entre las zonas. Las consecuencias de los ciberataques sobre distintas zonas también son muy diferentes.

Un buen ejemplo de diferentes zonas operativas en los ICSs se encuentran en las modernas redes eléctricas. Al mismo tiempo ejemplifica como los ICSs modernos son sistemas muy complejos, los cuales frecuentemente no se ajustan a un modelo de red general para la ciberseguridad. Por ejemplo la red inteligente es una arquitectura sofisticada de comunicación, control, vigilancia, y automatización, con el propósito de mejorar la manera en la cual se genera, distribuye, y consume electricidad. La red inteligente es distribuida a través de vastas regiones geográficas, e incluye múltiples zonas, incluyendo múltiples zonas de campo, cada una muy compleja por si mismas.

Como se percibe una red inteligente se divide en cuatro áreas principales: generación, transmisión, y distribución de energía, como también en la medición avanzada en las instalaciones del usuario final. Cada una de las áreas principales son un sistema muy vasto y complejo por si mismo con múltiples zonas de campo y control, los cuales necesitan interactuar el uno con el otro. La red inteligente también resalta la complejidad y diversidad a niveles empresariales. La red inteligente requiere una variedad de servicios de energía y servicios back-office, los cuales aunque estén incluidas en la zona empresarial, podrían considerarse como su propia zona. Se puede argumentar los enfoques actuales en ciberseguridad para la red inteligente protegen adecuadamente las zonas superiores (como las redes TI), pues comparten muchos puntos en común con otros sistemas a nivel empresarial. La generación de energía, transmisión, y áreas de distribución sin embargo, dependen en gran medida sobre CPSs, e incluyen vastas zonas de campo distribuidos constituidas de ICSs con funcionalidad dedicada y limitada. Proteger estos sistemas complejos de ciber ataques es un reto de enormes proporciones, los cuales los diseñadores deben superar junto con limitaciones adicionales, tales como requerimientos en seguridad y fiabilidad.

Fuentes:

https://en.wikipedia.org/wiki/Industrial_control_system
https://www.researchgate.net/figure/Industrial-control-system-ICS-netwo…

Una diferencia clave entre un Sistema de Control Industrial y sistemas tradicionales para Tecnologías de Información (TI), es los ICS interactúan fuertemente con el entorno físico. Los ICSs y todos los CPSs (Sistemas Ciber Físicos) son cibersistemas, y por lo tanto son vulnerables a ciberataques. Esta conexión entre el mundo físico por lo tanto, presenta retos y oportunidades únicas.

Los CPSs integran recursos computacionales, capacidades para comunicación, sensores, y accionadores, en un esfuerzo por vigilar y controlas procesos físicos. Los CPSs son encontrados en infraestructuras críticas como redes para transporte, vehículos aéreos no tripulados, generación de energía nuclear, redes para la distribución de energía eléctrica, redes para la distribución de agua o gas, y sistemas avanzados para la comunicación.

En los sistemas tradicionales con infraestructuras críticas, se realizan grandes esfuerzos para resolver problemas sobre seguridad y fiabilidad, además de desarrollar las técnicas adecuadas para detección, aislamiento, y recuperación de fallas. En CPSs sin embargo los elementos “ciber” adicionales introducen vulnerabilidades específicas, las cuales no son abordadas directamente por las prácticas computacionales de tolerancia a fallos y fiabilidad. Abordar el elemento ciber en la seguridad y fiabilidad CPS es de suma importancia, pues la introducción de CPSs altamente integrados dentro de infraestructuras críticas y sistemas emergentes, podría conducir hacia situaciones donde los ciberataques contra los CPS podrían afectar negativamente la seguridad pública.

Fuentes:

https://csrc.nist.gov/glossary/term/industrial_control_system
https://en.wikipedia.org/wiki/Cyber-physical_system