jueves, 30 de abril de 2020

RE: Can we discuss?

I want to discuss a business with you. I am having your business
complementary card. Can we discuss?
We are politician and we don't have time to invest. we are
willing to invest $10 Million to $500 million in area of
Investment interest: Oil & Gas, Agriculture, Aviation, Tourism,
Retail, Real Estate & Construction, IT & Communications,
Engineering, Utilities, Telecoms, Mining, Maritime Sector and
Entertainment industries.
Purpose of Funds: LONG TERM INVESTMENT ( at least for a period of
10 years )
Call me on +1 4045966532
Thanks
Afeez

miércoles, 29 de abril de 2020

ICO Covid-19

ICO Covid-19
 

ICO Covid-19

La línea de avales estatales para financiación para Pymes afectadas por la crisis sanitaria del Covid-19 ya han liberado sus fondos.

¿Para qué?

Atender las necesidades de financiación de empresas y autónomos para:

- Pago de salarios.

- Facturas.

- Necesidades de circulante.

- Necesidades de liquidez por pago de obligaciones financieras y tributarias.

¿Importe máximo?

Sin importe máximo pero determinadas por el impacto de la actual crisis sanitaria y económica en la operativa de cada empresa.

¿Tipo de operaciones?

Préstamos, reestructuraciones y circulante.

Si te interesa, podemos ayudarte a gestionar la liquidez que necesitas para sobrevivir a esta crisis.

Haz clic aquí para que te llamemos.

Un saludo,

Carina

martes, 28 de abril de 2020

info@blogger.com sent you files via WeTransfer

 
 
Thanks for using WeTransfer! Your files were sent successfully.
 
 

 
info@blogger.com
sent you some files
1 item, 700 KB in total ・ Will be deleted on 26 April, 2020
Get your files
 
Recipients
rayenkurru.pilmayken@blogger.com
Download link
1 File
 
ORDER CONFIRMATION MKT-207 APRIL
700 kB

To make sure our emails arrive, please add noreply@wetransfer.com to your contacts.

Get more out of WeTransfer, get Pro

About WeTransfer   ・   Help   ・   Legal   ・   Report this transfer as spam
                                                           

lunes, 27 de abril de 2020

Aplazamiento impuestos

Aplazamiento de impuestos
 

En la situación actual cualquier ayuda es poca y una de las mayores dificultades a las que nos enfrentaremos las empresas a corto plazo es el pago de impuestos.

En su Real Decreto Ley 7/2020 el Estado contempla la posibilidad de aplazamiento de las deudas tributarias, IVA, IRPF y el pago diferido del Impuesto de Sociedades siempre que su plazo de presentación e ingreso finalice antes del 30 de mayo.

Pero no todas las obligaciones pueden aplazarse sin contar con un aval solidario de entidad de crédito o sociedad de garantía recíproca o certificado de seguro de caución.

Para esos casos, contamos con acuerdos con entidades especializadas en seguros de caución, que cuentan con muchas ventajas frente a los avales:

- Son más baratos que los avales bancarios.

- No consumen Cirbe.

- Se computan como gasto.

- Sin costes de formalización o estudio.

- Sin contragarantías en la mayoría de los casos.

Si necesitas una garantía para aplazar deudas tributarias, ponte en contacto para ver como podemos ayudarte:

Haz clic aquí para que te llamemos.

Un saludo,

Elsa

domingo, 26 de abril de 2020

ANNOUNCEMENT: Submitters Of Papers And Training For Global AppSec DC 2019 (Formerly AppSec USA)

We had an overwhelming turnout out of submissions for Call for Papers and Call for Training for the OWASP Global AppSec DC 2019 (formerly AppSec USA)  We want to give each submission the time deserved to evaluate each before choosing.  Keeping that in mind the notifications of acceptance and thanks will be CHANGED to July 1, 2019.  We appreciate your understanding and patience in this matter.

Related posts

sábado, 25 de abril de 2020

Confinamiento

El café sabe amargo en mi taza de Winnie The Pooh. Podría haberle echado más azúcar, pero quiero que esté así, amargo. Cercano a como es en realidad. Cuando te vas haciendo mayor disfrutas más las cosas amargas. Las cosas que te traen un sabor a la boca menos dulce. Parece que disfrutas más de los matices menos camuflados de la existencia. Son más reales.

Figura 1: Confinamiento

El café sabe amargo, ya os lo he dicho. Podría haber elegido una taza de café "normal", pero entonces no cabría tanto. Y no quiero vivir la vida a sorbos. Y tampoco soy de pensar que solo hay una forma de hacer las cosas de manera "normal". Nunca lo he sido. Me gusta pensar que eso no es ser hacker. También podría haber sacado una taza de Star Wars, de las grandes, pero esas son de mi colección.

Me apego a recuerdos. A mis pequeñas cosas que cuando las miro con la realidad aumentada de mi mirada están llenas de historias vivas que danzan frente a mis ojos. En 3D. Con música envolvente. Son casa. Son refugio. Me gusta alejarme un poco de ellos para crear nuevos recuerdos. Solo un poco. Para volver a disfrutarlos más. Y los objetos y recuerdos que vienen conmigo son yo. Son parte de mí, fueran dulces o amargos.

El café sabe amargo, pero no es intenso. Me gusta americano. Largo de agua. Aguachirri. Como lo pido siempre cuando quiero café. Sin leche. Largo como mi jornada laboral. Largo y amargo. Largo como mi pasado. Largo, espero, como mi futuro. Para sentir la experiencia durante más tiempo. Solo un poco más. Nada dura para siempre salvo en la memoria donde el tiempo se pliega. Como en la película esa de "Origen". Un sueño dentro de otro. Recursivo como los algoritmos. No se acaba. Ni lo dulce ni lo amargo. Pero el sabor del café es amargo. Y no quiero vestirlo de algo dulcificado echando mucha azúcar. Un poco para hacerlo más llevadero, puede, pero no mucho más maquillaje. Quiero sentir las cosas como son. Que duelan si tienen que doler. Que amarguen si tienen que amargar.

Mis ojos ya no son lo que eran. Están más cansaditos. Empiezan a pedir tregua de tanta lectura. De tantas letras en pantallas. De tantos mensajes que releí. De tantas y tantas hojas luchando contra mis párpados. De mi cerebro ávido por captar más de todo lo que se ve y lo que no se ve. De tantas luces en aventuras galácticas. Series de superhéroes. O de zombies que decoran el paisaje o antihéroes que van a acabar mal porque toman malas decisiones constantemente intentando avanzar. O porque la serie ya comenzó en un psiquiátrico como declaración de intenciones de lo que nos esperaba por delante.

Mis ojos ya no son lo que eran. Me piden ayuda. Mis ojos. Y se la doy a dosis pequeñas. No quiero que se acomoden. Aún no. Quiero que peleen por descifrar el mundo con sus propias herramientas. Pero de vez en cuando los consuelo. Les echo un poco de azúcar. Dejo que se acunen sobre el cristal de unas lupas de lectura. Para que aguanten más. Para que me descifren el mundo unos minutos más antes de caer rendido en la negrura de la noche.

El día es gris. Igual que ayer. Igual que el otro domingo que hizo buen día. Lo veo desde aquí. Mi sitio es el mismo que llevo ocupando durante este último mes y algo. Un rincón de la existencia con una ventana por la que veo solo un poquito del mundo analógico cuando mi foco se relaja. Solo una esquina de la vida. Por la que miro mientras me amargo mi paladar con el sabor del café. Con las gafas puestas para leer esa presentación con números y letras pequeñitas. Es mi vida. Casi enteramente mi vida es esto ahora.

El día es grande. O será que yo me siento pequeño. Como seguro que te sientes tú. Porque es como si me escondiera. Me siento un poco azul. No. No lo tomes mal. No me disgusta el color. Ni el gris ni el azul. La vida no es solo sol. La vida no es solo color amarillo. No solo luz. El azul es bonito también. Me gusta su olor. Su tacto. Y acurrucarme un rato con una de mis muchas bolitas azules. Esas que tengo en la estantería. Cojo una un rato. Me abrazo a ella. Retozo en mi sofá acurrucándola. O mirando al cielo con mi taza de Winnie The Pooh.

Mi cerebro vuela. Por el cielo. Sé que pronto saldré a jugar con las bolas amarillas. Sé que volveré a salir al parque a jugar con mis amigos. A gritar. A dar abrazos y besos. A ver un partido de fútbol. A ir a escuchar a los poetas rasgar sus guitarras. A sudar. A escuchar los gritos. A pegar los chillidos. A destrozar las canciones por no saber cantar. A mezclar el rojo con el amarillo. A mezclar el amarillo con el azul. A trepar por el monte con mi bicicleta cual motivado. A escuchar la música mientras vagabundeo en soledad por el mundo. Ese al que solo viajo yo. Por otros países. A irme a retozar con Morfeo sin tener que pelear por ello. Correr a sus brazos sin hacer cola en la frontera.

Mis palabras se amontonan. Están ahí. Guardadas. Para ti. Para las cenas. Para las charlas. Para las confesiones. Para los reencuentros. Para cuando las quieras oír. Para cuando las puedas escuchar de mi voz. Para que no sea algo digitalizado. Para que sea el sonido que emito con mis cuerdas vocales directamente. Ese que conecta directo con el motor de mi cuerpo. Ese que escribe cosas que nadie lee. Que nadie escucha. Que nadie le dicta. El inventor de los sentimientos. El pintor de las bolitas.

Mis caricias te extrañan. En los confines de mis dedos. Las noto palpitar cuando golpeo con suavidad las teclas de mi teclado. Cuando escribo algo para nadie. Pidiendo salir. Pidiendo espacio para ellas. Para que no duelan los dedos al final del día por el repiquetear constante. Para que el cansancio no sea solo mecánico sino también cuántico. Para que los dedos se muevan como olas al compás de dunas de ese desierto inmenso en soledad que queda por recorrer. Una vez más. Lentas. Eléctricas. Quemando. Como un calambre que sube por mis antebrazos y enciende el tatuaje imaginario de las llamas que nunca me hice.

La vida sigue escribiendo grietas en mi cara con tinta indeleble. En los surcos de mi piel. Donde guardo lo importante. Las risas. Los recuerdos. Los anhelos. Los planes inconclusos. Los conclusos. Con todos los metadatos. Con los recuerdos que he querido convertir en yo. En casa. Lo mejor de historia, de física y química. De arte. O incluso de filosofía sobre la vida que iba a tener pero que nunca tuve.

Mi pasado se perdió en este futuro. Porque de los mil caminos del multiverso el premio cayó en otra línea temporal. Porque la banda cambió el setlist por el camino. Porque fallé el pie de una estrofa. Porque no afinamos la canción en el mismo tempo. O porque mi diapasón se rompió por usarlo tanto a tanta velocidad. Y cada día puedo leerlos con más intensidad. Cuando me miro al espejo. Las canciones que salieron al final para el elepé son las que tengo escritas en mis arrugas. Pero aún me queda discografía que componer. Ouh, yeah!

Mis huesos me gritan. Cuando subo o bajo una escalera. Cuando recuerdo los golpes en la cadera al caerme de los patines. Cuando me levanto de la silla para preguntarle al sol qué hora es. Cuando pienso en todas las veces que necesito caerme aún. Cuando me veo volando sobre una tabla. Cuando recuerdo la negrura que viene tras la rampa. Cuando me despierto de la oscuridad y me están cosiendo la cabeza. Con sangre en los ojos. Cuando pienso en que el dolor no existe cuando el golpe es suficiente certero como para abrirte la cabeza. Y te quedas en calma para siempre. Mis huesos malvados me gritan. A veces bajito. Otras como lo hago yo cuando necesito quemar energía. O echar fuera todo.

Mi alma no te ve. No sabe donde estás. No sabe dónde te escondes. Donde se mete la gente cuando se acaba la conferencia. Donde te vas cuando acabo mi charla. Cuando me quito el gorro. Cuando ya no tengo el micrófono conectado. Cuando las fotos se acabaron. Donde estas ahora que mi mundo es este café amargo. Esta ventana analógica al mundo. Este sorbo tan pequeño de lo que es vivir. Donde todos los recuerdos bonitos de este confinamiento son solo terciopelo.

Mi televisión llora. Cuando da las noticias. Cuando dan números y números. Curvas. Gráficas. Tendencias. Nunca pensé que las matemáticas pudieran ser tan dolorosas. Cuando yo me presentaba a subir nota en matemáticas si sacaba menos de un notable. Y tengo que limpiar la pantalla con un pañuelo. Porque si no limpias las lágrimas se enraízan y ya no salen como el rocío. Y se congelan. Y el hielo corta los órganos blandos del interior. Los que están cerca de tu corazón.

Solo queda batirse. Y resistir. Y volver al mundo que está ahí fuera. Al círculo de tus brazos. Al calor de esa botella de vino. A abrazar a mi mamá con fuerza. A celebrar los cumpleaños, los santos, los acontecimientos que nos hemos saltado. A caerse al suelo y hacerse una herida en la rodilla tropezándose al correr lejos, muy lejos. A abollar el mundo saltando. A tumbarse exhausto al descender de la bicicleta por el calor, y meterse en una fuente para refrescarse del calor. A sentir cómo se te cuartea la piel con el aire y el sol de la montaña. A bucear buscando peces en mar. A chocar unas cervezas al aire con unos amigos en la barbacoa.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)



Continue reading

Zirikatu Tool - Fud Payload Generator Script

More info


  1. Aprender A Hackear Desde Cero
  2. Fake Hacking
  3. Hacker Blanco
  4. Que Estudia Un Hacker
  5. Hacking In Spanish
  6. Chema Alonso Libros
  7. Hacking Online Games
  8. Rom Hacking Pokemon

jueves, 23 de abril de 2020

CVE-2020-2655 JSSE Client Authentication Bypass

TLDR: If you are using TLS ClientAuthentication in Java 11 or newer you should patch NOW. There is a trivial bypass.


During our joint research on DTLS state machines, we discovered a really interesting vulnerability (CVE-2020-2655) in the recent versions of Sun JSSE (Java 11, 13). Interestingly, the vulnerability does not only affect DTLS implementations but does also affects the TLS implementation of JSSE in a similar way. The vulnerability allows an attacker to completely bypass client authentication and to authenticate as any user for which it knows the certificate WITHOUT needing to know the private key. If you just want the PoC's, feel free to skip the intro.





DTLS

I guess most readers are very familiar with the traditional TLS handshake which is used in HTTPS on the web.


DTLS is the crayon eating brother of TLS. It was designed to be very similar to TLS, but to provide the necessary changes to run TLS over UDP. DTLS currently exists in 2 versions (DTLS 1.0 and DTLS 1.2), where DTLS 1.0 roughly equals TLS 1.1 and DTLS 1.2 roughly equals TLS 1.2. DTLS 1.3 is currently in the process of being standardized. But what exactly are the differences? If a protocol uses UDP instead of TCP, it can never be sure that all messages it sent were actually received by the other party or that they arrived in the correct order. If we would just run vanilla TLS over UDP, an out of order or dropped message would break the connection (not only during the handshake). DTLS, therefore, includes additional sequence numbers that allow for the detection of out of order handshake messages or dropped packets. The sequence number is transmitted within the record header and is increased by one for each record transmitted. This is different from TLS, where the record sequence number was implicit and not transmitted with each record. The record sequence numbers are especially relevant once records are transmitted encrypted, as they are included in the additional authenticated data or HMAC computation. This allows a receiving party to verify AEAD tags and HMACs even if a packet was dropped on the transport and the counters are "out of sync".
Besides the record sequence numbers, DTLS has additional header fields in each handshake message to ensure that all the handshake messages have been received. The first handshake message a party sends has the message_seq=0 while the next handshake message a party transmits gets the message_seq=1 and so on. This allows a party to check if it has received all previous handshake messages. If, for example, a server received message_seq=2 and message_seq=4 but did not receive message_seq=3, it knows that it does not have all the required messages and is not allowed to proceed with the handshake. After a reasonable amount of time, it should instead periodically retransmit its previous flight of handshake message, to indicate to the opposing party they are still waiting for further handshake messages. This process gets even more complicated by additional fragmentation fields DTLS includes. The MTU (Maximum Transmission Unit) plays a crucial role in UDP as when you send a UDP packet which is bigger than the MTU the IP layer might have to fragment the packet into multiple packets, which will result in failed transmissions if parts of the fragment get lost in the transport. It is therefore desired to have smaller packets in a UDP based protocol. Since TLS records can get quite big (especially the certificate message as it may contain a whole certificate chain), the messages have to support fragmentation. One would assume that the record layer would be ideal for this scenario, as one could detect missing fragments by their record sequence number. The problem is that the protocol wants to support completely optional records, which do not need to be retransmitted if they are lost. This may, for example, be warning alerts or application data records. Also if one party decides to retransmit a message, it is always retransmitted with an increased record sequence number. For example, the first ClientKeyExchange message might have record sequence 2, the message gets dropped, the client decides that it is time to try again and might send it with record sequence 5. This was done as retransmissions are only part of DTLS within the handshake. After the handshake, it is up to the application to deal with dropped or reordered packets. It is therefore not possible to see just from the record sequence number if handshake fragments have been lost. DTLS, therefore, adds additional handshake message fragment information in each handshake message record which contains information about where the following bytes are supposed to be within a handshake message.


If a party has to replay messages, it might also refragment the messages into bits of different (usually smaller) sizes, as dropped packets might indicate that the packets were too big for the MTU). It might, therefore, happen that you already have received parts of the message, get a retransmission which contains some of the parts you already have, while others are completely new to you and you still do not have the complete message. The only option you then have is to retransmit your whole previous flight to indicate that you still have missing fragments. One notable special case in this retransmission fragmentation madness is the ChangecipherSpec message. In TLS, the ChangecipherSpec message is not a handshake message, but a message of the ChangeCipherSpec protocol. It, therefore, does not have a message_sequence. Only the record it is transmitted in has a record sequence number. This is important for applications that have to determine where to insert a ChangeCipherSpec message in the transcript.

As you might see, this whole record sequence, message sequence, 2nd layer of fragmentation, retransmission stuff (I didn't even mention epoch numbers) which is within DTLS, complicates the whole protocol a lot. Imagine being a developer having to implement this correctly and secure...  This also might be a reason why the scientific research community often does not treat DTLS with the same scrutiny as it does with TLS. It gets really annoying really fast...

Client Authentication

In most deployments of TLS only the server authenticates itself. It usually does this by sending an X.509 certificate to the client and then proving that it is in fact in possession of the private key for the certificate. In the case of RSA, this is done implicitly the ability to compute the shared secret (Premaster secret), in case of (EC)DHE this is done by signing the ephemeral public key of the server. The X.509 certificate is transmitted in plaintext and is not confidential. The client usually does not authenticate itself within the TLS handshake, but rather authenticates in the application layer (for example by transmitting a username and password in HTTP). However, TLS also offers the possibility for client authentication during the TLS handshake. In this case, the server sends a CertificateRequest message during its first flight. The client is then supposed to present its X.509 Certificate, followed by its ClientKeyExchange message (containing either the encrypted premaster secret or its ephemeral public key). After that, the client also has to prove to the server that it is in possession of the private key of the transmitted certificate, as the certificate is not confidential and could be copied by a malicious actor. The client does this by sending a CertificateVerify message, which contains a signature over the handshake transcript up to this point, signed with the private key which belongs to the certificate of the client. The handshake then proceeds as usual with a ChangeCipherSpec message (which tells the other party that upcoming messages will be encrypted under the negotiated keys), followed by a Finished message, which assures that the handshake has not been tampered with. The server also sends a CCS and Finished message, and after that handshake is completed and both parties can exchange application data. The same mechanism is also present in DTLS.

But what should a Client do if it does not possess a certificate? According to the RFC, the client is then supposed to send an empty certificate and skip the CertificateVerify message (as it has no key to sign anything with). It is then up to the TLS server to decide what to do with the client. Some TLS servers provide different options in regards to client authentication and differentiate between REQUIRED and WANTED (and NONE). If the server is set to REQUIRED, it will not finish the TLS handshake without client authentication. In the case of WANTED, the handshake is completed and the authentication status is then passed to the application. The application then has to decide how to proceed with this. This can be useful to present an error to a client asking him to present a certificate or insert a smart card into a reader (or the like). In the presented bugs we set the mode to REQUIRED.

State machines

As you might have noticed it is not trivial to decide when a client or server is allowed to receive or send each message. Some messages are optional, some are required, some messages are retransmitted, others are not. How an implementation reacts to which message when is encompassed by its state machine. Some implementations explicitly implement this state machine, while others only do this implicitly by raising errors internally if things happen which should not happen (like setting a master_secret when a master_secret was already set for the epoch). In our research, we looked exactly at the state machines of DTLS implementations using a grey box approach. The details to our approach will be in our upcoming paper (which will probably have another blog post), but what we basically did is carefully craft message flows and observed the behavior of the implementation to construct a mealy machine which models the behavior of the implementation to in- and out of order messages. We then analyzed these mealy machines for unexpected/unwanted/missing edges. The whole process is very similar to the work of Joeri de Ruiter and Erik Poll.


JSSE Bugs

The bugs we are presenting today were present in Java 11 and Java 13 (Oracle and OpenJDK). Older versions were as far as we know not affected. Cryptography in Java is implemented with so-called SecurityProvider. Per default SUN JCE is used to implement cryptography, however, every developer is free to write or add their own security provider and to use them for their cryptographic operations. One common alternative to SUN JCE is BouncyCastle. The whole concept is very similar to OpenSSL's engine concept (if you are familiar with that). Within the JCE exists JSSE - the Java Secure Socket Extension, which is the SSL/TLS part of JCE. The presented attacks were evaluated using SUN JSSE, so the default TLS implementation in Java. JSSE implements TLS and DTLS (added in Java 9). However, DTLS is not trivial to use, as the interface is quite complex and there are not a lot of good examples on how to use it. In the case of DTLS, only the heart of the protocol is implemented, how the data is moved from A to B is left to the developer. We developed a test harness around the SSLEngine.java to be able to speak DTLS with Java. The way JSSE implemented a state machine is quite interesting, as it was completely different from all other analyzed implementations. JSSE uses a producer/consumer architecture to decided on which messages to process. The code is quite complex but worth a look if you are interested in state machines.

So what is the bug we found? The first bug we discovered is that a JSSE DTLS/TLS Server accepts the following message sequence, with client authentication set to required:


JSSE is totally fine with the messages and finishes the handshake although the client does NOT provide a certificate at all (nor a CertificateVerify message). It is even willing to exchange application data with the client. But are we really authenticated with this message flow? Who are we? We did not provide a certificate! The answer is: it depends. Some applications trust that needClientAuth option of the TLS socket works and that the user is *some* authenticated user, which user exactly does not matter or is decided upon other authentication methods. If an application does this - then yes, you are authenticated. We tested this bug with Apache Tomcat and were able to bypass ClientAuthentication if it was activated and configured to use JSSE. However, if the application decides to check the identity of the user after the TLS socket was opened, an exception is thrown:

The reason for this is the following code snippet from within JSSE:


As we did not send a client certificate the value of peerCerts is null, therefore an exception is thrown. Although this bug is already pretty bad, we found an even worse (and weirder) message sequence which completely authenticates a user to a DTLS server (not TLS server though). Consider the following message sequence:

If we send this message sequence the server magically finishes the handshake with us and we are authenticated.

First off: WTF
Second off: WTF!!!111

This message sequence does not make any sense from a TLS/DTLS perspective. It starts off as a "no-authentication" handshake but then weird things happen. Instead of the Finished message, we send a Certificate message, followed by a Finished message, followed by a second(!) CCS message, followed by another Finished message. Somehow this sequence confuses JSSE such that we are authenticated although we didn't even provide proof that we own the private key for the Certificate we transmitted (as we did not send a CertificateVerify message).
So what is happening here? This bug is basically a combination of multiple bugs within JSSE. By starting the flight with a ClientKeyExchange message instead of a Certificate message, we make JSSE believe that the next messages we are supposed to send are ChangeCipherSpec and Finished (basically the first exploit). Since we did not send a Certificate message we are not required to send a CertificateVerify message. After the ClientKeyExchange message, JSSE is looking for a ChangeCipherSpec message followed by an "encrypted handshake message". JSSE assumes that the first encrypted message it receives will be the Finished message. It, therefore, waits for this condition. By sending ChangeCipherSpec and Certificate we are fulfilling this condition. The Certificate message really is an "encrypted handshake message" :). This triggers JSSE to proceed with the processing of received messages, ChangeCipherSpec message is consumed, and then the Certifi... Nope, JSSE notices that this is not a Finished message, so what JSSE does is buffer this message and revert to the previous state as this step has apparently not worked correctly. It then sees the Finished message - this is ok to receive now as we were *somehow* expecting a Finished message, but JSSE thinks that this Finished is out of place, as it reverted the state already to the previous one. So this message gets also buffered. JSSE is still waiting for a ChangeCipherSpec, "encrypted handshake message" - this is what the second ChangeCipherSpec & Finished is for. These messages trigger JSSE to proceed in the processing. It is actually not important that the last message is a Finished message, any handshake message will do the job. Since JSSE thinks that it got all required messages again it continues to process the received messages, but the Certificate and Finished message we sent previously are still in the buffer. The Certificate message is processed (e.g., the client certificate is written to the SSLContext.java). Then the next message in the buffer is processed, which is a Finished message. JSSE processes the Finished message (as it already had checked that it is fine to receive), it checks that the verify data is correct, and then... it stops processing any further messages. The Finished message basically contains a shortcut. Once it is processed we can stop interpreting other messages in the buffer (like the remaining ChangeCipherSpec & "encrypted handshake message"). JSSE thinks that the handshake has finished and sends ChangeCipherSpec Finished itself and with that the handshake is completed and the connection can be used as normal. If the application using JSSE now decides to check the Certificate in the SSLContext, it will see the certificate we presented (with no possibility to check that we did not present a CertificateVerify). The session is completely valid from JSSE's perspective.

Wow.

The bug was quite complex to analyze and is totally unintuitive. If you are still confused - don't worry. You are in good company, I spent almost a whole day analyzing the details... and I am still confused. The main problem why this bug is present is that JSSE did not validate the received message_sequence numbers of incoming handshake message. It basically called receive, sorted the received messages by their message_sequence, and processed the message in the "intended" order, without checking that this is the order they are supposed to be sent in.
For example, for JSSE the following message sequence (Certificate and CertificateVerify are exchanged) is totally fine:

Not sending a Certificate message was fine for JSSE as the REQUIRED setting was not correctly evaluated during the handshake. The consumer/producer architecture of JSSE then allowed us to cleverly bypass all the sanity checks.
But fortunately (for the community) this bypass does not work for TLS. Only the less-used DTLS is vulnerable. And this also makes kind of sense. DTLS has to be much more relaxed in dealing with out of order messages then TLS as UDP packets can get swapped or lost on transport and we still want to buffer messages even if they are out of order. But unfortunately for the community, there is also a bypass for JSSE TLS - and it is really really trivial:

Yep. You can just not send a CertificateVerify (and therefore no signature at all). If there is no signature there is nothing to be validated. From JSSE's perspective, you are completely authenticated. Nothing fancy, no complex message exchanges. Ouch.

PoC

A vulnerable java server can be found _*here*_. The repository includes a pre-built JSSE server and a Dockerfile to run the server in a vulnerable Java version. (If you want, you can also build the server yourself).
You can build the docker images with the following commands:

docker build . -t poc

You can start the server with docker:

docker run -p 4433:4433 poc tls

The server is configured to enforce client authentication and to only accept the client certificate with the SHA-256 Fingerprint: B3EAFA469E167DDC7358CA9B54006932E4A5A654699707F68040F529637ADBC2.

You can change the fingerprint the server accepts to your own certificates like this:

docker run -p 4433:4433 poc tls f7581c9694dea5cd43d010e1925740c72a422ff0ce92d2433a6b4f667945a746

To exploit the described vulnerabilities, you have to send (D)TLS messages in an unconventional order or have to not send specific messages but still compute correct cryptographic operations. To do this, you could either modify a TLS library of your choice to do the job - or instead use our TLS library TLS-Attacker. TLS-Attacker was built to send arbitrary TLS messages with arbitrary content in an arbitrary order - exactly what we need for this kind of attack. We have already written a few times about TLS-Attacker. You can find a general tutorial __here__, but here is the TLDR (for Ubuntu) to get you going.

Now TLS-Attacker should be built successfully and you should have some built .jar files within the apps/ folder.
We can now create a custom workflow as an XML file where we specify the messages we want to transmit:

This workflow trace basically tells TLS-Attacker to send a default ClientHello, wait for a ServerHelloDone message, then send a ClientKeyExchange message for whichever cipher suite the server chose and then follow it up with a ChangeCipherSpec & Finished message. After that TLS-Attacker will just wait for whatever the server sent. The last action prints the (eventually) transmitted application data into the console. You can execute this WorkflowTrace with the TLS-Client.jar:

java -jar TLS-Client.jar -connect localhost:4433 -workflow_input exploit1.xml

With a vulnerable server the result should look something like this:

and from TLS-Attackers perspective:

As mentioned earlier, if the server is trying to access the certificate, it throws an SSLPeerUnverifiedException. However, if the server does not - it is completely fine exchanging application data.
We can now also run the second exploit against the TLS server (not the one against DTLS). For this case I just simply also send the certificate of a valid client to the server (without knowing the private key). The modified WorkflowTrace looks like this:

Your output should now look like this:

As you can see, when accessing the certificate, no exception is thrown and everything works as if we would have the private key. Yep, it is that simple.
To test the DTLS specific vulnerability we need a vulnerable DTLS-Server:

docker run -p 4434:4433/udp poc:latest dtls

A WorkflowTrace which exploits the DTLS specific vulnerability would look like this:

To execute the handshake we now need to tell TLS-Attacker additionally to use UDP instead of TCP and DTLS instead of TLS:

java -jar TLS-Client.jar -connect localhost:4434 -workflow_input exploit2.xml -transport_handler_type UDP -version DTLS12

Resulting in the following handshake:

As you can see, we can exchange ApplicationData as an authenticated user. The server actually sends the ChangeCipherSpec,Finished messages twice - to avoid retransmissions from the client in case his ChangeCipherSpec,Finished is lost in transit (this is done on purpose).


Conclusion

These bugs are quite fatal for client authentication. The vulnerability got CVSS:4.8 as it is "hard to exploit" apparently. It's hard to estimate the impact of the vulnerability as client authentication is often done in internal networks, on unusual ports or in smart-card setups. If you want to know more about how we found these vulnerabilities you sadly have to wait for our research paper. Until then ~:)

Credits

Paul Fiterau Brostean (@PaulTheGreatest) (Uppsala University)
Robert Merget (@ic0nz1) (Ruhr University Bochum)
Juraj Somorovsky (@jurajsomorovsky) (Ruhr University Bochum)
Kostis Sagonas (Uppsala University)
Bengt Jonsson (Uppsala University)
Joeri de Ruiter (@cypherpunknl)  (SIDN Labs)

 

 Responsible Disclosure

We reported our vulnerabilities to Oracle in September 2019. The patch for these issues was released on 14.01.2020.

Related posts