blog

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

Ping verifica la conectividad a nivel de IP con otra computadora TCP/IP, enviando mensajes Echo Request (ICMP). Se muestra la recepción con mensajes Echo Reply, además de tiempos de ida y retorno. Ping es el principal comando TCP/IP utilizado para solucionar problemas de conectividad, accesibilidad, y resolución de nombres. Utilizado sin parámetros este comando muestra su ayuda.

Se puede también utilizar este comando para evaluar ya sea el nombre de la computadora y su dirección IP. Si el ping a la dirección IP tiene éxito, pero hacer lo mismo con el nombre de la computadora no la tiene, entonces se podría tener un problema en la resolución de nombres. En este caso asegurarse el nombre de la computadora especificada, puede ser resuelta a través de un archivo host local utilizando consultas DNS, o a través de técnicas para la resolución de nombres NetBIOS.

Se ejecuta el comando ping sin opción, lo cual muestra un resumen de sus opciones.

C:\>ping

Se sugiere ejecutar ping con privilegios de administrador. Así mismo para detener su ejecución e factible utilizar la combinación de teclas “CTRL + c”.

C:\>ping 66.22 .13.14

La opción “-f” especifica los mensajes Echo Request son enviados con la opción “No fragmentar” en la cabecera IP ajustada con 1 (disponible únicamente con IPv4). El mensaje Echo Request no puede ser fragmentado por los encaminadores en la ruta hacia el destino. Este parámetro es útil para solucionar problemas de PMTU o Unidad Máxima para Transmisión.

La opción “-l”, especifica la longitud en bytes, del campo de Datos en los mensajes Echo Request. Por defecto es 32. El tamaño máximo es 65,527.

C:\> ping -f -l 1500 66.22 .13.14

La respuesta “Packets needs to be fragmented but DF set”, indica la trama es muy grande para estar en la red, y necesita ser fragmentada. El paquete no fue enviado, pues se utiliza la opción “-f” con el comando ping, devolviendo este error.

Se pueden intentar diferentes valores hasta encontrar el tamaño máximo de la trama. Para el presente ejemplo es de 1404. Lo cual indica 1404 bytes son el tamaño máximo de la trama sobre esta máquina en red.

C:\> ping -f -l 1404 66.22 .13.14

En lo referente a descubrir aquello lo cual ocurre cuando el TTL expira. Cada trama en la red tienen un TTL definido. Si el TTL alcanza el valor de cero, el encaminador descarta el paquete. Este mecanismo previene la pérdida de paquetes.

La opción “-i” define el TTL o tiempo de vida. Siendo el máximo valor TTL de 255.

C:\> ping -i 3 66.22 .13.14

El mensaje “TTL expired in transit” significa el encaminador descarta las tramas porque el TTL ha expirado (alcanzó cero).

Se pueden ir modificado los valores de la opción “-i” hasta obtener un ping exitoso. Para el presente ejemplo ese valor es de 13 saltos. Esto implica el valor TTL es de 13

C:\> ping -i 13 66.22 .13.14

Con estos procedimientos es posible recopilar información sobre un host, utilizando el comando ping, como su dirección IP, contabilizar los satos, y valor del tamaño máximo de la trama permitida en la red.

Fuentes:

https://docs.microsoft.com/en-us/windows-server/administration/windows-…

theHarvester es una herramienta simple de utilizar, poderosa, y efectiva, diseñada para ser utilizada en las etapas previas de una prueba de penetración o evaluaciones de equipo rojo. Utiliza recopilación de inteligencia desde fuentes abiertas, para ayudar a determinar la superficie de amenaza externa de la compañía en Internet. La herramienta obtiene correos electrónicos, nombres, subdominios, direcciones IPs, y URLs, utilizando múltiples fuentes de datos públicos.

Se ejecuta theHarvester con la opción “-h”, lo cual muestra un mensaje de ayuda.

$ theHarvester - h

Ahora se ejecuta la herramienta para obtener información de los empleados relacionados con una organización o empresa desde LinkedIn.

LinkedIn es la red profesional más grande del mundo. Se puede utilizar LinkedIn para encontrar el trabajo o internado correcto, conectar y fortalecer relaciones profesionales, además de aprender los conocimientos necesarios para tener éxito en una profesión.

La opción “-d” define el nombre de la compañía o dominio a buscar.

La opción “-l” lista el número de los resultados producto de la búsqueda, por defecto es de 500.

La opción “-d” define la fuente donde se realizará la búsqueda. Para propósitos de la presente demostración se define “linkedin”.

$ theHarvester -d presidencia .gob. pe -l 100 -b linkedin

Los resultados presentados por theHarvester se dividen en dos secciones. La primera corresponde a los usuarios encontrados en LinkedIn. Aquí se utiliza el motor de búsqueda Google, específica la búsqueda de usuarios en LinkedIn.

La segunda sección corresponder a enlaces de LinkedIn encontrados.

Mencionar también es factible definir la opción “-b linkedin_links”. Especifica la búsqueda de usuarios en LinkedIn para el dominio en evaluación (Utiliza el buscador Google)

Es importante recordar, como profesionales en Hacking Ético y Pruebas de Penetración es necesario corroborar todos los resultados obtenidos por las herramientas.

Información similar podría ser obtenida realizando la búsqueda “site:linkedin.com presidencia .gob .pe”, en el motor de búsqueda Google

Los resultados obtenidos por theHarvester incluyen algunos falsos positivos, es decir no corresponden a empleados directamente relacionados con el dominio buscado.

Consecuentemente es factible realizar otra búsqueda directamente en Google, la cual se ajuste mejor a nuestros requerimientos; como por ejemplo “site:linkedin.com presidencia de la república del perú”

Algunos de los resultados obtenidos con esta búsqueda manual, también han sido obtenidos por la herramienta theHarvester, en su sección “Enlaces de LinkedIn Encontrados”.

Fuentes:

https://github.com/laramies/theHarvester
https://www.linkedin.com/help/linkedin/answer/a548441/what-is-linkedin-…-?lang=en