When you want to check the security of a system, the first step is to gather as much information as possible to get to know the vulnerabilities that could affect you. There are several techniques and tools that directly facilitate or automate this. The problem comes when the process interacts with the system so that effectively exploits a vulnerability or any other normal operation is affected. If done in a controlled manner, the consequences may be minimal, imperceptible to users, but if a critical system, it is unacceptable that might imperil its proper functioning, but is under control. When we are not allowed to interact with the system, so we can only WYSIWYG technique, ie to observe network traffic and to draw all possible information from there. Let us assume that the traffic is used on IP technology known as Ethernet, ZigBee or WiFi for example.
First, the bad news. The information obtained from observing the traffic is not only incomplete, but is not 100% accurate. After all there is to capture traffic at the right time and trust that the system has not changed in a way that generates traffic that is outside of what would be normal. In this post we will assume that has not changed anything with the sole intention to mislead or deceive.
Second good news. You can extract more data than it seems. Let's start with the easiest / obvious:
* IP address and link (MAC) in most technologies, the MAC address indicates who is the manufacturer. Especially the wifi drivers and mature technologies that have the classical Ethernet vulnerabilities, some of them quite serious.
* Ports open and closed. Just look at the attempts to establish a connection (SYN) and responses (SYN-ACK/RST). Although we can assume that each port is used for what is reserved, looking at the traffic can be sure that the protocol is expected.
* Broadcast messages. Other applications or devices to make announcements to the entire network using the broadcast address and may have known vulnerabilities.
* Application-level messages. Some applications provide clear information of the operating system software, version and even the type of processor that uses a particular machine. Example, banners ssh and ftp servers or user agent field of web browsers including
* If you establish connections to servers for updates on what information can be obtained and possibly what software version is used.
Obviously there are more complicated techniques. The best known study is based on the peculiarities of the TCP (1, 2, 3 and others) and IP (1) to try to differentiate between operating systems. In the standard there are some fields whose values are not defined in all situations or can take a value within a range. This means that every implementation has small differences that are especially notable in the phases of establishment and termination of the connection. There are several tools that implement this idea. The best known is undoubtedly p0f. These are the fields that are most useful to identify the operating system when a connection is being established:
* Size of the window. They usually take a characteristic value for each operating system that can be fixed, or an integer multiple of the MTU (Maximum Transmission Unit) or MSS (Maximum Segment Size).
* TTL (Time To Live). Usually changes between different families of operating systems.
* Flag "do not fragment." Some operating systems activate while others do not. Its value is irrelevant to establish a connection.
* TCP Options. A TCP segment may contain a variety of options. This is where you can see really big differences, so what options are present and in what order and what values they have. Some of the most important ones, the maximum segment size, window scaling, and the timestamp option that indicates support selective ACKS.
* Errors and strange behaviors. Defying all logic, there are errors in implementations of the standards. It does not mean that there is some vulnerability, but at some point it may not meet the standard and still meet the standard behavior is not logical. One of my favorites is an old version of the Linux kernel, which in little-endian processors advertised a window size of 512 or 16,384, while in big-endian processors became 2 and 64 respectively
There's more technical, some of them quite complex and give us information about the system to investigate.
* Specific features in common protocols such as ICMP, NetBIOS, DNS. For example, the response to an ICMP timestamp of some operating systems is little-endian when it should be big-endian.
* Characteristics of the IP header, such as the use of options or detectable patterns in the "identification".
* Analysis of the behavior of TCP. In the algorithms that define TCP there are certain decisions that can take the implementer and vary from one pile to another. For example, the initial size of the congestion window may be 1 or 2 segments, or different operating systems may implement different versions of fast-recovery or other.
* The timestamp field in the TCP options grows linearly with time. By linear regression over time of several timestamp, you can calculate how many times this value is updated per second, a value that varies from one operating system to another.
As you can see, capture and analyze network traffic can give us plenty of clues that we are facing what they seem. Furthermore it is always more fun to ask the manager to tell us that is installed
.........................................................................
Cuando se quiere comprobar la seguridad de un sistema, el primer paso es recopilar la mayor cantidad de información posible hasta llegar a conocer que vulnerabilidades podrían afectarle. Hay varias técnicas y herramientas que facilitan o directamente automatizan esto. El problema viene cuando en el proceso se interactúa con el sistema de manera que efectivamente se explota una vulnerabilidad o por cualquier otro motivo el funcionamiento normal se ve afectado. Si se realiza de una manera controlada, las consecuencias pueden ser mínimas, imperceptibles para los usuarios, pero en caso de ser un sistema crítico, es inaceptable que se pueda poner en riesgo su correcto funcionamiento, aunque se haga bajo control. Cuando no se nos permite interactuar con el sistema, tan solo nos queda la técnica WYSIWYG , es decir, observar el tráfico de red y sacar toda la información posible de ahí. Vamos a suponer que se utiliza el tráfico es IP sobre las tecnologías conocidas como Ethernet, wifi o zigbee por ejemplo.
En primer lugar, las malas noticias. La información que se obtiene de observar el tráfico no solo es incompleta, sino que no es fiable al 100%. Al fin y al cabo hay que capturar tráfico en el momento adecuado y confiar en que el sistema no se ha modificado de manera que genera tráfico que se sale de lo que sería habitual. En este post vamos a suponer que no se ha modificado nada con la única intención de confundir o engañar.
En segundo lugar las buenas noticias. Se pueden extraer más datos de los que parece. Empecemos por lo más fácil/obvio:
* Dirección IP y de enlace (MAC) En la mayoría de las tecnologías, la dirección MAC indica quien es el fabricante. Los drivers especialmente de wifi y tecnologías menos maduras que la clásica Ethernet tienen vulnerabilidades, algunas de ellas muy graves.
* Puertos abiertos y cerrados. Simplemente observamos los intentos de establecer una conexión (SYN) y las respuestas (SYN-ACK/RST). Aunque podemos suponer que cada puerto se utiliza para lo que está reservado, mirando el tráfico se puede comprobar que el protocolo es el esperado.
* Mensajes de broadcast. Otras aplicaciones o dispositivos que hacen anuncios a toda la red usando la dirección de broadcast y que pueden tener vulnerabilidades conocidas.
* Mensajes a nivel de aplicación. Algunas aplicaciones dan información clara del sistema operativo, el software, la versión e incluso el tipo de procesador que utiliza una máquina en concreto. Ejemplo, banners de servidores ftp y ssh o el campo user-agent de los navegadores web entre otros
* Si se establecen conexiones a servidores de actualizaciones puede obtenerse información de qué software y posiblemente qué versión se utiliza.
Lógicamente hay técnicas más complicadas. Las más conocidas se basan en estudiar las peculiaridades de los protocolos TCP (1, 2, 3 y otros) e IP (1) para intentar diferenciar entre sistemas operativos. En el estándar hay ciertos campos cuyos valores no están definidos en todas las situaciones o pueden tomar un valor dentro de un rango. Esto hace que cada implementación tenga pequeñas diferencias que son especialmente notables en las fases de establecimiento y finalización de la conexión. Hay varias herramientas que implementan esta idea. La más conocida seguramente sea p0f. Estos son los campos que resultan más útiles a la hora de identificar el sistema operativo cuando se está estableciendo una conexión:
* Tamaño de la ventana. Suelen tomar un valor característico para cada sistema operativo que puede ser fijo, o un múltiplo entero del MTU (Maximum Transmission Unit) o del MSS (Maximum Segment Size).
* TTL (Time To Live). Habitualmente cambia entre diferentes familias de sistemas operativos.
* flag "do not fragment". Algunos sistemas operativos lo activan mientras que otros no. Su valor es indiferente al establecer una conexión.
* Opciones TCP. Un segmento TCP puede incluir una gran variedad de opciones. Es aquí donde realmente se pueden apreciar grandes diferencias, tanto en qué opciones están presente como en qué orden y qué valores tienen. Algunas de las más importantes son, el tamaño máximo de segmento, el escalado de ventana, el timestamp y la opción que indica el soporte de ACKs selectivos.
* Errores y comportamientos extraños. Desafiando toda lógica, hay errores en las implementaciones de los estándares. No significa que haya alguna vulnerabilidad sino que en algún momento es posible que no cumpla el estándar o que aún cumpliendo el estándar su comportamiento no es lógico. Uno de mis favoritos es una versión antigua del kernel de Linux, que en procesadores little-endian anunciaban un tamaño de ventana de 512 o 16384, mientras que en procesadores big-endian se convertía en 2 y 64 respectivamente
Aún hay más técnicas, algunas de ellas bastante complejas que nos dan información acerca del sistema a investigar.
* Peculiaridades en protocolos comunes, como ICMP, NETBIOS, DNS. Por ejemplo, la respuesta a un ICMP de tipo timestamp de algunos sistemas operativos es little-endian cuando debería ser big-endian.
* Particularidades en las cabeceras IP, como el uso de opciones o patrones detectables en el campo "identification".
* Análisis del comportamiento de TCP. En los algoritmos que definen TCP hay ciertas decisiones que puede tomar el implementador y que varían de una pila a otra. Por ejemplo el tamaño inicial de la ventana de congestión puede ser de 1 o 2 segmentos, o distintos sistemas operativos pueden implementar diferentes versiones de fast-recovery u otros.
* El campo timestamp en las opciones de TCP crece linealmente con el tiempo. Haciendo la regresión lineal con el tiempo de varios timestamp, se puede calcular cuantas veces se actualiza este valor por segundo, valor que varía de un sistema operativo a otro.
Como pueden ver, capturar y analizar el tráfico de red nos puede dar bastantes más pistas de a que nos enfrentamos de lo que parece. Además siempre es más divertido que pedir al administrador que nos diga que hay instalado
No hay comentarios:
Publicar un comentario