Most of the web applications I see are kinda binary when it comes to CSRF protection; either they have one implemented using CSRF tokens (and more-or-less covering the different functions of the web application) or there is no protection at all. Usually, it is the latter case. However, from time to time I see application checking the Referer HTTP header.
A couple months ago I had to deal with an application that was checking the Referer as a CSRF prevention mechanism, but when this header was stripped from the request, the CSRF PoC worked. BTW it is common practice to accept empty Referer, mainly to avoid breaking functionality.
The OWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet tells us that this defense approach is a baaad omen, but finding a universal and simple solution on the Internetz to strip the Referer header took somewhat more time than I expected, so I decided that the stuff that I found might be useful for others too.
Solutions for Referer header strip
Most of the techniques I have found were way too complicated for my taste. For example, when I start reading a blog post from Egor Homakov to find a solution to a problem, I know that I am going to:
learn something very cool;
have a serious headache from all the new info at the end.
This blog post from him is a bit lighter and covers some useful theoretical background, so make sure you read that first before you continue reading this post. He shows a few nice tricks to strip the Referer, but I was wondering; maybe there is an easier way?
Rich Lundeen (aka WebstersProdigy) made an excellent blog post on stripping the Referer header (again, make sure you read that one first before you continue). The HTTPS to HTTP trick is probably the most well-known one, general and easy enough, but it quickly fails the moment you have an application that only runs over HTTPS (this was my case).
The data method is not browser independent but the about:blank trick works well for some simple requests. Unfortunately, in my case the request I had to attack with CSRF was too complex and I wanted to use XMLHttpRequest. He mentions that in theory, there is anonymous flag for CORS, but he could not get it work. I also tried it, but... it did not work for me either.
Krzysztof Kotowicz also wrote a blog post on Referer strip, coming to similar conclusions as Rich Lundeen, mostly using the data method.
Finally, I bumped into Johannes Ullrich's ISC diary on Referer header and that led to me W3C's Referrer Policy. So just to make a dumb little PoC and show that relying on Referer is a not a good idea, you can simply use the "referrer" meta tag (yes, that is two "r"-s there).
As you can see, there is quite a lot of ways to strip the Referer HTTP header from the request, so it really should not be considered a good defense against CSRF. My preferred way to make is PoC is with the meta tag, but hey, if you got any better solution for this, use the comment field down there and let me know! :)
El artículo de hoy lo escribo por algunas razones, las cuales comentaré en breve. El punto para reflexionar es: ¿Qué es un bypass deUAC? Para muchos una técnica desprestigiada en un Ethical Hacking, para otros una vía a tener en cuenta en la obtención de privilegios o la obtención de una shell en un nivel de integridad alto de Windows. Puedo equivocarme en lo que comente en este artículo o puede que tengas otra visión, pero vamos a ir viendo y matizando ciertos aspectos que cubren a esta técnica.
Figura 1: Cuando un Bypass de UAC en Windows es un "Bug" o una "Feature"
Por supuesto, si lo que quieres es aplicar Máxima Seguridad a tu Windows, esto es algo que se aplica en primer paso. Es decir, quitar la configuración por defecto y aplicar la que exige a todos los binarios la confirmación UAC, y no permite el autoelevado. Vamos un poco más allá para entenderlo. ¿Cómo nos protegemos de los bypasses de UAC? Vamos primero a ver la GPO, para lo que buscamos:
Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode
Ahí encontraremos uno de los motivos por los que los bypasses de UAC funcionan. Como se puede ver en la imagen, se pedirá consentimiento, por parte del UAC, solo a los procesos que no sean binarios de Windows. Realmente, hay un mayor detalle en esto que comentaré a continuación.
Figura 3: Política para UAC para los binarios que no son de Windows
Aparte de ser un "binario de Windows", que esto no es más que se encuentre firmado por Microsoft, éste debe ser además un binario con una directiva en el Manifest con "Auto-Elevate" con valor "True". Es decir, le están diciendo al sistema que el binario, aparte de estar firmado por Microsoft, éste tiene una especie de "carnet especial" o "pase especial" y que no debe rendir cuentas al UAC.
Por último, otra de las comprobaciones que hace el sistema es que el binario se esté ejecutando en una ruta "privilegiada", por ejemplo, System32. Si recordamos el bypass de UAC de Mocking Directory Trusted, gracias a un fallo de interpretación de una de las APIs internas del sistema se podía "saltar" esta protección.
Desde el punto de vista del pentesting tenemos que tener en cuenta algunas cosas también. Lo que parece más lógico, pero que a veces la gente puede no entender bien es que, para pasar a un nivel de integridad alto, debes de estar en otro nivel de integridad, inferior se entiende.
En el caso de un bypass de UAC debes partir desde un nivel de integridad medio. Por esta razón, el módulo de Metasploit, cuando se hace cualquier bypass de UAC de forma automática, nos muestra los diferentes chequeos, entre ellos el nivel de integridad actual.
Como se puede observar, una de las cosas que se chequean es el nivel de integridad. Si estuviéramos en un nivel de integridad alto y no nos hubiéramos dado cuenta, sería una cosa muy extraña, porque demostraríamos no tener el control de lo que hacemos, pues ya estaríamos "elevados", por lo que no tendría sentido realizar esta operación. Puede que nuestro proceso no se encuentre en un nivel de integridad medio y estemos más abajo, tendremos problemas también. Debemos entender por qué estamos y debemos estar en este nivel de integridad.
Esto va relacionado con el tipo de usuario que debemos ser. Solo podemos ser un usuario que forme parte del grupo administradores, pero que no esté ejecutando el proceso como administrador. Esto es importante. Es otra cosa que a veces no queda clara.
Necesitamos que un usuario que tiene privilegios para realizar acciones como administrador, haya ejecutado un proceso y que no haya hecho uso de dichos privilegios para, una vez comprometido su proceso, podamos aprovechar este hecho y hacer el bypass de UAC. Puede ser lioso, pero es lógico. Si el usuario hubiera lanzado el proceso como administrador, el nivel de integridad ya sería alto, no medio.
Como se veía en la imagen anterior, el módulo de Metasploit comprueba si el usuario al que pertenece el proceso comprometido es o no es del grupo administradores. Si no es del grupo administradores, ¿Qué ocurre? Es sencillo, la política de comportamiento del UAC asociada es diferente. Tal y como se puede ver en la imagen, la acción por defecto para un usuario que no pertenece al grupo administradores es que el UAC pida credenciales.
Figura 7: Selección de opción de pedir credenciales
Figura 8: Configuraciones de los Modos UAC en Windows 7
¿Era más seguro? A priori, y basándonos en este artículo, sí. Pero las quejas llegaron. Los usuarios no estaban preparados para ello y se rebajaron algunas configuraciones. Esto fue en Windows 7, si no recuerdo mal, que puedo recordarlo mal.
Y un bypass de UAC entonces, ¿dónde tiene sentido?
Yo siempre digo en las clases o en los cursos/talleres que un bypass de UAC se enseña en local, pero su aplicación tiene sentido en remoto. Es decir, por motivos de divulgación y educación se puede enseñar en local todo el proceso de lo que ocurre, no solo quedaros con se lanza un módulo de Metasploit y listo, eso es la automatización y está bien, una vez que se conoce qué ocurre por detrás.
Miramos con ProcMon y Proccess Explorer lo que ocurre, se estudian diferentes técnicas: Environment Injection, DLL Hijacking, Fileless… O jugamos con nuestro querido UAC-A-Mola y vemos qué cosas se pueden hacer.
Figura 9: UAC-a-Mola: Bypassing UAC using Fileless techniques
Pero a la hora de poner en práctica o de utilizar en un Ethical Hacking solo tiene sentido en remoto, porque si tienes un usuario que cumple los requisitos del bypass de UAC y tienes acceso físico te vale ejecutar:
"botón derecho -> Ejecutar como administrador"
Bien, pero ¿cómo hacemos eso en remoto? Es complejo. Vamos a tener una shell remota con la que podemos ver fácilmente si tenemos la posibilidad de utilizar técnicas de bypass de UAC y si estamos en ese caso, ¿cómo se aplican? ¿Ejecutas botón derecho -> admin? No. No puedes. Aquí es dónde tiene todo el sentido del mundo las técnicas de bypass de UAC.
Desde una shell invocarás a un binario que cumple las tres necesidades comentadas anteriormente, previamente habrás preparado el camino para que la ejecución de dicho binario desemboque en que el nuevo proceso haga uso de tu código, y como ese proceso se estará ejecutando en un nivel de integridad alto, tu código también se ejecutará en el mismo nivel de integridad.
Ahí tenemos el bypass, porque gracias a las características del binario, el UAC dejará ejecutarlo. Y en esto se resume. Hemos hablado mucho en este blog sobre diferentes bypasses de UAC, cómo han ido evolucionando las técnicas, cómo a veces se simplificaban y ahí están los artículos
Para mí: ¿Qué no es un bypass de UAC?
Si desde la GUI de cualquier binario se puede ejecutar código, pero no se puede hacer a través de una consola, para mí no es un bypass de UAC efectivo. Puede que, técnicamente se haga un bypass de UAC, porque evitemos que se ejecute el UAC y se ejecute un código nuestro. ¿Nos aporta algo más que darle al botón derecho -> "ejecutar como administrador"? Eso es lo que nos tenemos que preguntar, es decir, ¿podremos utilizarlo?
Aquí tenemos una bifurcación: bypass de UAC efectivo para el pentesting o bypass de UAC que prueba un concepto, pero no es efectivo para el pentesting. Como ejemplo podemos utilizar algunos ejemplos con interfaces gráficas.
Técnicamente, lo que veremos ahora consigue hacer que un CMD se ejecute y no salte el UAC. Sabemos que cuando se intenta ejecutar una CMD con privilegio, el UAC saltará para confirmación del usuario o petición de credenciales en el caso de un usuario que no sea del grupo administradores. Tenemos que pensar, ¿se puede usar en un pentest? Eso es más complejo. Lo primero es utilizar un binario de los que sabemos que ejecutan en un nivel de integridad alto sin que el UAC salte, por ejemplo, el eventvwr.exe en Windows 10.
Figura 10: EventViewer tiene Auto-Elevate True
Desde aquí, todo lo que sea código que se ejecute heredará el nivel de integridad alto, por lo que podemos ir al menú "Help". La opción "Help Topics" nos muestra la ayuda del visor de eventos. Pinchando con el botón derecho en la parte donde se muestra el texto se puede ver una opción que es "View Source".
Figura 11: View Source
Al ejecutar "View Source" se ve un bloc de notas con un texto. Claro, si analizamos el bloc de notas con Proccess Explorer podremos ver que el notepad.exe se ejecuta en un nivel de integridad alto. Aquí ya tenemos lo que buscamos, si abrimos un cuadro de diálogo tenemos la posibilidad de ejecutar lo que se quiera.
Figura 12: notepad.exe con nivel de integridad alto
Abrimos el cuadro de diálogo y buscamos en System32 el binario del CMD. En vez de abrirlo sobre el notepad.exe, botón derecho y abrir el cmd.exe. Ahí lo tenemos. ¿Podríamos haberlo hecho a través de una shell? Si encontramos la forma de hacer que todo esto se pueda hacer desde una línea de comandos, tendríamos, desde mi opinión, un bypass de UCA efectivo, si no, simplemente hemos demostrado o enseñado que hay código que puede ser ejecutado sin que el UAC salte, pero no termina de ser efectivo en un pentesting o en un Ethical Hacking.
Figura 13: CMD.exe elevado sin UAC
En la siguiente imagen de Process Explorer se puede ver el nivel de integridad y cómo desde el mmc.exe (abierto con eventvwr.exe directamente) sin que el UAC salte, porque es un binario que cumple las condiciones comentadas anteriormente, se van abriendo diferentes procesos hasta llegar a una cmd.exe.
Figura 14: Nivel de Integridad "High"
Vale, pero, ¿es efectivo? Cuando se lee bypass de UAC, una de las cosas que debemos valorar es efectivo o no. Generalmente, cuando hablamos de bypass de UAC entendemos que es una vía por la que se obtiene privilegios saltándonos el UAC y nunca a través de algo gráfico, porque no habría diferencia con "botón derecho -> ejecutar como admin". El debate está servido. Tú decides.
In the last two years, we changed the TLS-Attacker Project quite a lot but kept silent about most changes we implemented. Since we do not have so much time to keep up with the documentation (we are researchers and not developers in the end), we thought about creating a small series on some of our recent changes to the project on this blog.
We hope this gives you an idea on how to use the most recent version (TLS-Attacker 2.8). If you feel like you found a bug, don't hesitate to contact me via GitHub/Mail/Twitter. This post assumes that you have some idea what this is all about. If you have no idea, checkout the original paper from Juraj or our project on GitHub.
TLDR: TLS-Attacker is a framework which allows you to send arbitrary protocol flows.
So, what changed since the release of the original paper in 2016? Quite a lot! We discovered that we could make the framework much more powerful by adding some new concepts to the code which I want to show you now.
Action System
In the first Version of TLS-Attacker (1.x), WorkflowTraces looked like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Although this design looks straight forward, it lacks flexibility. In this design, a WorkflowTrace is basically a list of messages. Each message is annotated with a <messageIssuer>, to tell TLS-Attacker that it should either try to receive this message or send it itself. If you now want to support more advanced workflows, for example for renegotiation or session resumption, TLS-Attacker will soon reach its limits. There is also a missing angle for fuzzing purposes. TLS-Attacker will by default try to use the correct parameters for the message creation, and then apply the modifications afterward. But what if we want to manipulate parameters of the connection which influence the creation of messages? This was not possible in the old version, therefore, we created our action system. With this action system, a WorkflowTrace does not only consist of a list of messages but a list of actions. The most basic actions are the Send- and ReceiveAction. These actions allow you to basically recreate the previous behavior of TLS-Attacker 1.x . Here is an example to show how the same workflow would look like in the newest TLS-Attacker version:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see, the <messageIssuer> tags are gone. Instead, you now indicate with the type of action how you want to deal with the message. Another important thing: TLS-Attacker uses WorkflowTraces as an input as well as an output format. In the old version, once a WorkflowTrace was executed it was hard to see what actually happened. Especially, if you specify what messages you expect to receive. In the old version, your WorkflowTrace could change during execution. This was very confusing and we, therefore, changed the way the receiving of messages works. The ReceiveAction has a list of <expectedMessages>. You can specify what you expect the other party to do. This is mostly interesting for performance tricks (more on that in another post), but can also be used to validate that your workflow executedAsPlanned. Once you execute your ReceiveAction an additional <messages> tag will pop up in the ReceiveAction to show you what has actually been observed. Your original WorkflowTrace stays intact.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
During the execution, TLS-Attacker will execute the actions one after the other. There are specific configuration options with which you can control what TLS-Attacker should do in the case of an error. By default, TLS-Attacker will never stop, and just execute whatever is next.
Configs
As you might have seen the <messageIssuer> tags are not the only thing which is missing. Additionally, the cipher suites, compression algorithms, point formats, and supported curves are missing. This is no coincidence. A big change in TLS-Attacker 2.x is the separation of the WorkflowTrace from the parameter configuration and the context. To explain how this works I have to talk about how the new TLS-Attacker version creates messages. Per default, the WorkflowTrace does not contain the actual contents of the messages. But let us step into TLS-Attackers point of view. For example, what should TLS-Attacker do with the following WorkflowTrace:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Usually, the RSAClientKeyExchange message is constructed with the public key from the received certificate message. But in this WorkflowTrace, we did not receive a certificate message yet. So what public key are we supposed to use? The previous version had "some" key hardcoded. The new version does not have these default values hardcoded but allows you as the user to define the default values for missing values, or how our own messages should be created. For this purpose, we introduced the new concept of Configs. A Config is a file/class which you can provide to TLS-Attacker in addition to a WorkflowTrace, to define how TLS-Attacker should behave, and how TLS-Attacker should create its messages (even in the absence of needed parameters). For this purpose, TLS-Attacker has a default Config, with all the known hardcoded values. It is basically a long list of possible parameters and configuration options. We chose sane values for most things, but you might have other ideas on how to do things. You can execute a WorkflowTrace with a specific config. The provided Config will then overwrite all existing default values with your specified values. If you do not specify a certain value, the default value will be used. I will get back to how Configs work, once we played a little bit with TLS-Attacker.
TLS-Attacker ships with a few example applications (found in the "apps/" folder after you built the project). While TLS-Attacker 1.x was mostly a standalone tool, we currently see TLS-Attacker more as a library which we can use by our more sophisticated projects. The current example applications are:
TLS-Client (A TLS-Client to execute WorkflowTraces with)
TLS-Server (A TLS-Server to execute WorkflowTraces with)
Attacks (We'll talk about this in another blog post)
TLS-Forensics (We'll talk about this in another blog post)
TLS-Mitm (We'll talk about this in another blog post)
TraceTool (We'll talk about this in another blog post)
TLS-Client
The TLS-Client is a simple TLS-Client. Per default, it executes a handshake for the default selected cipher suite (RSA). The only mandatory parameter is the server you want to connect to (-connect).
The most trivial command you can start it with is:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note: The example tool does not like "https://" or other protocol information. Just provide a hostname and port
Depending on the host you chose your output might look like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So what is going on here? Let's start with the first execution. As I already mentioned. TLS-Attacker constructs the default WorkflowTrace based on the default selected cipher suite. When you run the client, the WorkflowExecutor (part of TLS-Attacker which is responsible for the execution of a WorkflowTrace) will try to execute the handshake. For this purpose, it will first start the TCP connection. This is what you see here:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After that, it will execute the actions specified in the default WorkflowTrace. The default WorkflowTrace looks something like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is basically what you see in the console output. The first action which gets executed is the SendAction with the ClientHello.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Then, we expect to receive messages. Since we want to be an RSA handshake, we do not expect a ServerKeyExchange message, but only want a ServerHello, Certificate and a ServerHelloDone message.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
and finally, we want to receive a ChangeCipherSpec and Finished Message:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the first execution, these steps all seem to have worked. But why did they fail in the second execution? The reason is that our default Config does not only allow specify RSA cipher suites but creates ClientHello messages which also contain elliptic curve cipher suites. Depending on the server you are testing with, the server will either select and RSA cipher suite, or an elliptic curve one. This means, that the WorkflowTrace will not executeAsPlanned. The server will send an additional ECDHEServerKeyExchange. If we would look at the details of the ServerHello message we would also see that an (ephemeral) elliptic curve cipher suite is selected:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Since our WorkflowTrace is configured to send an RSAClientKeyExchange message next, it will just do that:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note: ClientKeyExchangeMessage all have the same type field, but are implemented inside of TLS-Attacker as different messages
Since this RSAClientKeyExchange does not make a lot of sense for the server, it rejects this message with a DECODE_ERROR alert:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If we would change the Config of TLS-Attacker, we could change the way our ClientHello is constructed. If we specify only RSA cipher suites, the server has no choice but to select an RSA one (or immediately terminate the connection). We added command line flags for the most common Config changes. Let's try to change the default cipher suite to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see, we now executed a complete ephemeral elliptic curve handshake. This is, because the -cipher flag changed the <defaultSelectedCiphersuite> parameter (among others) in the Config. Based on this parameter the default WorkflowTrace is constructed. If you want, you can specify multiple cipher suites at once, by seperating them with a comma.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We can do the same change by supplying TLS-Attacker with a custom Config via XML. To this we need to create a new file (I will name it config.xml) like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
You can then load the Config with the -config flag:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For a complete reference of the supported Config options, you can check out the default_config.xml. Most Config options should be self-explanatory, for others, you might want to check where and how they are used in the code (sorry).
Now let's try to execute an arbitrary WorkflowTrace. To do this, we need to store our WorkflowTrace in a file and load it with the -workflow_input parameter. I just created the following WorkflowTrace:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see I just send a ServerHello message instead of a ClientHello message at the beginning of the handshake. This should obviously never happen but let's see how the tested server reacts to this. We can execute the workflow with the following command:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The server (correctly) responded with an UNEXPECTED_MESSAGE alert. Great!
Output parameters & Modifications
You are now familiar with the most basic concepts of TLS-Attacker, so let's dive into other things TLS-Attacker can do for you. As a TLS-Attacker user, you are sometimes interested in the actual values which are used during a WorkflowTrace execution. For this purpose, we introduced the -workflow_output flag. With this parameter, you can ask TLS-Attacker to store the executed WorkflowTrace with all its values in a file. Let's try to execute our last created WorkflowTrace, and store the output WorkflowTrace in the file out.xml:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As you can see, although the input WorkflowTrace was very short, the output trace is quite noisy. TLS-Attacker will display all its intermediate values and modification points (this is where the modifiable variable concept becomes interesting). You can also execute the output workflow again.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Note that at this point there is a common misunderstanding: TLS-Attacker will reset the WorkflowTrace before it executes it again. This means, it will delete all intermediate values you see in the WorkflowTrace and recompute them dynamically. This means that if you change a value within <originalValue> tags, your changes will just be ignored. If you want to influence the values TLS-Attacker uses, you either have to manipulate the Config (as already shown) or apply modifications to TLS-Attackers ModifiableVariables. The concept of ModifiableVariables is mostly unchanged to the previous version, but we will show you how to do this real quick anyway.
So let us imagine we want to manipulate a value in the WorkflowTrace using a ModifiableVariable via XML. First, we have to select a field which we want to manipulate. I will choose the protocol version field in the ServerHello message we sent. In the WorkflowTrace this looked like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For historical reasons, 0x0303 means TLS 1.2. 0x0300 was SSL 3. When they introduced TLS 1.0 they chose 0x0301 and since then they just upgraded the minor version.
In order to manipulate this ModifiableVariable, we first need to know its type. In some cases it is currently non-trivial to determine the exact type, this is mostly undocumented (sorry). If you don't know the exact type of a field you currently have to look at the code. The following types and modifications are defined:
As a rule of thumb: If the value is only up to 1 byte of length we use a ModifiableByte. If the value is up to 4 bytes of length, but the values are used as a normal number (for example in length fields) it is a ModifiableInteger. Fields which are used as a number which are bigger than 4 bytes (for example a modulus) is usually a ModifiableBigInteger. Most other types are encoded as ModifiableByteArrays. The other types are very rare (we are currently working on making this whole process more transparent). Once you have found your type you have to select a modification to apply to it. For manual analysis, the most common modifications are the XOR modification and the explicit value modification. However, during fuzzing other modifications might be useful as well. Often times you just want to flip a bit and see how the server responds, or you want to directly overwrite a value. In this example, we want to overwrite a value. Let us force TLS-Attacker to send the version 0x3A3A. To do this I consult the ModifiableVariableREADME.md for the exact syntax. Since <protocolVersion> is a ModifiableByteArray I search in the ByteArray section.
I find the following snippet:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If I now want to change the value to 0x3A3A I modify my WorkflowTrace like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With Wireshark you can now observe that the protocol version got actually changed. You would also see the change if you would specify a -workflow_output or if you start the TLS-Client with the -debug flag.
More Actions
As I already hinted, TLS-Attacker has more actions to offer than just a basic Send- and ReceiveAction (50+ in total). The most useful, and easiest to understand actions are now introduced:
ActivateEncryptionAction
This action does basically what the CCS message does. It activates the currently "negotiated" parameters. If necessary values are missing in the context of the connection, they are drawn from the Config.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This action does the opposite. If the encryption was active, we now send unencrypted again.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Prints the last application data message either sent or received.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Prints the secrets (RSA) from the current connection. This includes the nonces, cipher suite, public key, modulus, premaster secret, master secret and verify data.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Resets the message digest. This is usually done if you want to perform a renegotiation.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Closes and reopens the connection. This can be useful if you want to analyze session resumption or similar things which involve more than one handshake.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Send a ClientKeyExchange message, and always chooses the correct one (depending on the current connection state). This is useful if you just don't care about the actual cipher suite and just want the handshake done.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(Maybe) sends a ServerKeyExchange message. This depends on the currently selected cipher suite. If the cipher suite requires the transmission of a ServerKeyExchange message, then a ServerKeyExchange message will be sent, otherwise, nothing is done. This is useful if you just don't care about the actual cipher suite and just want the handshake done.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This lets TLS-Attacker sleep for a specified amount of time (in ms).
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If TLS-Attacker helps you to find a bug in a TLS implementation, please acknowledge our tool(s). If you want to learn more about TLS, Juraj and I are also giving a Training about TLS at Ruhrsec (27.05.2019).
Welcome to my 3rd new tutorial of networking (Routing and Switching). In this blog you will able to watch an interesting video about basic device navigation such as changing device (router or switch) name, configuration of login password, configuring a device information, router IP addresses and many more.
What is router?
Router is a network layer device which is the 3rd layer in the OSI model which is used to communicate different networks. It is an intelligent device fixed at the boundary of network that connects to other networks and responsible for end to end delivery of the packet that requires an IP address which is known as the logical address which is the basic identity of the device just like our identity card number or roll number and so on, for the identification of source and destination devices. Router is the gateway of the network having two interfaces such as inbound and the outbound interface through which the traffic comes in from different networks and comes out traffic to the different networks.
What is an IP address?
Internet protocol (IP) address is a numeric label given to each and every device in the network for the identification of the device just like our roll numbers in collages, universities which identity each and every student uniquely everywhere. So same concept here, it is a logical address which is used whenever the device want to communicate outside the network that means to another network.
What is Switch?
Switch is basically layer 2 device, which is used to connect two or more than two devices with each other in the same network. It is an intelligent device which doesn't allow the broadcast. It requires Media access control (MAC) address to communicate within the network. Now let's move to the video for further.
Para consultas puedes usar el 
