Tuesday 30 June 2020

wanabidiiplace.blogspot.com : As you wish, BUT Its Worth It !!

Hello   wanabidiiplace.blogspot.com,
 
My name is  Raam Burke,  and I'm an SEO Specialist.
 
I was on your website and found, there are many scopes of improvements in the designing and development part. This will improve the overall usability and user-friendliness of your website.

If you are interested I'd be happy to send you No Obligation Audit Report for your website, our package, pricing and past work details, if you'd like to assess our work.
 
We could lower that cost and not compromise on quality!
 
Hope to hear back from you soon.

Kind Regards,
Raam Burke | Digital Marketing Specialist 

--------------------------------------------------------------------------
Note: Reply back with us "Interested" and get issue fixing plan now only at $199 (One Time)  

beacon
Read More :- "wanabidiiplace.blogspot.com : As you wish, BUT Its Worth It !!"

PRESENTACION PEDRO BOTE 2020

Related news
Read More :- "PRESENTACION PEDRO BOTE 2020"

Top 12 Best Websites To Learn Ethical Hacking 2018

  1. Hacked Gadgets: A resource for DIY project documentation as well as general gadget and technology news.
  2. Phrack Magazine: Digital hacking magazine.
  3. SecTools.Org: List of 75 security tools based on a 2003 vote by hackers.
  4. KitPloit: Leading source of Security Tools, Hacking Tools, CyberSecurity and Network Security.
  5. The Hacker News: The Hacker News — most trusted and widely-acknowledged online cyber security news magazine with in-depth technical coverage for cybersecurity.
  6. NFOHump: Offers up-to-date .NFO files and reviews on the latest pirate software releases.
  7. Packet Storm: Information Security Services, News, Files, Tools, Exploits, Advisories and Whitepapers.
  8. Hakin9: E-magazine offering in-depth looks at both attack and defense techniques and concentrates on difficult technical issues.
  9. Exploit DB: An archive of exploits and vulnerable software by Offensive Security. The site collects exploits from submissions and mailing lists and concentrates them in a single database.
  10. SecurityFocus: Provides security information to all members of the security community, from end users, security hobbyists and network administrators to security consultants, IT Managers, CIOs and CSOs.
  11. HackRead: HackRead is a News Platform that centers on InfoSec, Cyber Crime, Privacy, Surveillance, and Hacking News with full-scale reviews on Social Media Platforms.
  12. Metasploit: Find security issues, verify vulnerability mitigations & manage security assessments with Metasploit. Get the worlds best penetration testing software now.
Read More :- "Top 12 Best Websites To Learn Ethical Hacking 2018"

LOS SARCÓFAGOS DE BETHESDA, EL MENSAJE PALEOCRISTIANO DE LA SALVACIÓN Y DEL TRIUNFO SOBRE LA MUERTE.

 

"Tiempo divino, los sarcófagos de Bethesda" ("Tempo divino, i sarcofagi di Bethesda"), es el título de la exposición inaugurada desde el 7 de diciembre 2019 hasta el 29 de marzo de 2020 en los Museos Vaticanos. La exposición es muy sencilla, tan sólo se exhiben juntos dos sarcófagos casi gemelos con un tipo de representación repetida que se conoce como sarcófagos de Bethesda. Las dos obras son: la que conserva el propio museo, junto a la que proviene de la isla de Ischia, Italia. Para completar la exposición, faltarían una tercera lastra completa con el mismo motivo que se encuentra incrustada a 4 metros de altura en la fachada de la catedral de Tarragona, así como los fragmentos de otros trece que se han encontrado repartidos por otras partes del Imperio de Occidente. 

El sarcófago (resaltado en blanco) sobre la fachada de la catedral de Tarragona, España. Los constructores medievales lo empotraron en la fachada de la catedral respetando el valor artístico e iconográfico de la obra.  Mármol, 2,61 m. de largo por 0,61 m. de alto.  

La comparación de los dos sarcófagos que forman parte de la exposición nos ayuda a comprender tres hechos relevantes:
  • En primer lugar, la expansión notable del cristianismo por todo el Imperio en el siglo IV, especialmente en los reinados de los emperadores Valentiniano y Teodosio (354-395).
  • En segundo lugar, el empeño del cristianismo por crear modelos iconográficos universales que difundieran los principales mensajes de su religión. Es decir, la nueva religión del imperio, como había hecho el paganismo, buscaba su propio lenguaje repetitivo de figuras y escenas que actuaran a modo de mitos fácilmente interpretables por cualquiera.
  • Y en tercer lugar, que el medio que le pareció más útil para propagar esta iconografía fue el sarcófago. En él se tenía el "escenario" ideal para trasmitir mensajes por su formato alargado a modo de friso y por ser el receptáculo de los huesos de aquellos que murieron en la misma fe, lo que los convertían en objetos de contemplación por fieles y peregrinos. 
Mapa del cristianismo en la Antigüedad.

      Las escenas de milagros. La iconografía.

      El modelo conocido como sarcófago de Bethesda toma su nombre de un detalle central de la representación: la curación de un paralítico en el estanque de Betzatà, o Bethesda (ver Juan 5,1-18)En este modelo se repiten y reconocen también otras escenas evangélicas de milagros y episodios de la vida de Cristo por Galilea y Judea antes de comenzar la Pasión: la curación de dos ciegos en Cafarnaúm (narrada solo en Mateo 9, 27-31), la curación de la mujer hemorrágica también en Cafarnaúm (Mateo 9, 20-22), la llamada de Zaqueo en Jericó (Lucas 19, 1-10) y, finalmente, la entrada triunfal de Jesús en Jerusalem (Lucas 19, 29-38). 

      Los sarcófagos de Bethesda de Tarragona y del Museo Vaticano comparados.

      Las escenas componen una sucesión estudiada y cronológica de la misión terrenal del Jesucristo, "que pasó curando a todos los que estaban bajo el poder del diablo, porque Dios estaba con él "(Hechos 10: 37-38). Las curaciones revelan alegóricamente que Cristo libera con el bautismo las cadenas del pecado como fueron liberados de sus males los ciegos, la hemorroísa y el paralítico en la piscina de Betesda. Que Cristo se compadece del publicano Zaqueo. Y que gracias a que Cristo entró triunfante en Jerusalén para con su pasión y muerte posterior se pudiera redimir la humanidad. El sacrificio de Jesús derrotó a la muerte, por lo que el sarcófago se convierte en un lecho de descanso esperando la resurrección.

      Sarcófago de Bethesda de Ischia. Losa de mármol, 2,08 m. de largo por 0,58/0,59 de alto.

      La primera escena trascurre en Galilea, cuando Jesús salía por la puerta de la ciudad de Cafarnaúm. Le seguían dos ciegos gritando que les curara. Jesús se paró y les tocó sus ojos diciendo: ¡Hágase en vosotros según vuestra fe! y curaron. Los dos divulgaron su fama por toda aquella región. En el sarcófago, Jesús aparece acompañado por sus discípulos en tamaño gigante (jerarquía de tamaño) y con su mano toca a los que creen en él: a los dos ciegos les otorga de nuevo la vista. Las escenas se enmarcan en un bello detalle de arcos y entablamentos arquitectónicos. El mensaje alegórico es múltiple. Desde la realidad de la salvación en la fe de Cristo como que los dos ciegos representan a los dos pueblos, el judío y el gentil, los que creían en él y divulgaron por toda la tierra la venida de Jesucristo.


      La siguiente escena, también se desarrolla en Cafarnaúm. Dice las escrituras que  entre la multitud que salía a recibir a Cristo había una mujer que hacía doce años que padecía de hemorragias menstruales continuas. Había sufrido mucho a manos de varios médicos, y se había gastado todo lo que tenía sin que le hubiera servido de nada, pues en vez de mejorar, iba de mal en peor.  Cuando oyó hablar de Jesús, se le acercó por detrás entre la gente y le tocó el manto. Pensaba: «Si logro tocar siquiera su ropa, quedaré sana».  Al instante cesó su hemorragia, y se dio cuenta de que su cuerpo había quedado libre de esa aflicción. Jesús pregunta quién la ha tocado y la mujer le dice que ha sido ella; por su fe, la mujer queda curada. Por otro lado, en la religión hebrea tocar a una mujer con la menstruación era un tabú y Cristo, en vez de contagiarse, la purifica y la salva.

      Detalle del milagro de la curación del paralítico del sarcófago de Ischia.

      En la escena central del conjunto, Cristo se detiene frente al pórtico de entrada al estanque de Bethesda donde cura a un paralítico. Existía una leyenda de que en ese lugar de vez en cuando un ángel bajaba y removía sus aguas, cuando esto se producía proporcionaba la curación al primer enfermo que se bañara en él. Por ello, una multitud de personas se concentraba alrededor de la piscina. Entre los que se encuentra allí hay un hombre paralítico (escena inferior), que lleva mucho tiempo esperando a ser curado pero que su enfermedad le impide ser lo suficientemente rápido para ser el primero. Entre las dos escenas se representa un listón rectangular donde aparecen las ondulaciones del agua de la piscina. Así que (escena superior) Jesús lo sana, le ordena que se alce y se lleve la camilla sobre sus hombros. 

      Detalle del milagro de la curación del paralítico del sarcófago del museo Vaticano.

      Esta imagen central, la más importante del frontal, podría representar también al difunto propietario del sarcófago. La posición del personaje recuerda una escena de un banquete funerario pagano, tan habitual en Roma ya desde tiempos de los etruscos. De nuevo, la interpretación alegórica de la salvación, ya que sólo el poder del bautismo que ofrece Cristo al que cree en él es lo que puede liberar al hombre del mal y de la muerte. 
      ´
      La conversión de Zaqueo y la entrada triunfal de Cristo en Jerusalem. Detalle del sarcófago de Ischia.
      La cuarta escena representa el pasaje del evangelio de San Lucas sobre la conversión de Zaqueo cerca de Jericó. Zaqueo es un publicano, un judío que se había hecho rico como recaudador de impuestos para los romanos. Los publicanos se quedaban con un tanto por ciento de lo recaudado, a modo de salario, y ejercían la extorsión sobre el pueblo, por lo que eran considerados pecadores. Como era bajo de estatura y quiere ver a Jesús, que estaba rodeado por una multitud, el rico hombre toma la humillante decisión de subirse a un árbol como un niño. Jesús que le ve le dice que se baje del árbol porque ese día se alojaría en su casa. La gente congregada recrimina a Jesús el hecho de querer quedarse en la casa de un pecador. Zaqueo se defiende de las críticas diciendo que dará la mitad de sus riquezas a los pobres y devolverá cuatro veces más todo lo que había podido robar. Jesús le dice que se ha salvado.

      La entrada triunfal de Cristo en Jerusalem. Detalle del sarcófago de Tarragona.

      En la última escena del sarcófago se ve a Jesús sobre un pollino haciendo su entrada triunfal en Jerusalem. La gente lo recibe extendiendo mantas por el camino o cortando ramas o palmas de los árboles. La entrada del Mesías en la ciudad cumplirá su misterio salvador, con su Pasión y Resurrección. Es la imagen más clara del advenimiento del Salvador, del adventus.  La historia está llena de contrastes. Es la historia del rey que vino como un siervo humilde en un asno, no presumiendo en un corcel, no en vestiduras reales, sino con la ropa de los pobres y los humildes. Jesucristo no viene a conquistar a la fuerza como los reyes de la tierra, sino a ofrecer su propio sacrificio para la salvación de su pueblo. 
      Los rasgos artísticos de los sarcófagos paleocristianos.

      Ya hemos escrito sobre los sarcófagos paleocristianos en este blog, pero merece la  pena  señalar algunos rasgos artísticos que entroncan en la figuración tardo imperial romana y en el inicio del arte cristiano occidental.


      • Las escenas deben ser formalmente simples, claras, para quien las contempla las identifique e interprete sin duda. Para ello se recurre a la repetición de las composiciones y de una serie de elementos, poses y figuras de los personajes o, lo que es lo mismo, se recurre a la creación de un modelo iconográfico. El sarcófago que nos sirve de reflexión, el tipo de Bethesda, no puede ser más paradigmático en este sentido, puesto que a través de los tres que se han conservado enteros apenas hay variación en ciertos detalles de las escenas o personajes introducidos en ellas.
      • A Cristo se le representa estereotipado como joven imberbe, lo que suele ser habitual cuando aparece en su rol de sanador. El otro estereotipo, el de Cristo adulto barbado se reserva para difundir la imagen de Jesucristo como un maestro rodeado por sus discípulos impartiendo enseñanzas. Su imagen  bella e idealizada refuerza su naturaleza divinal. Su expresión amable e inocente es cercana a la joven y bello Apolo uno de los dioses paganos sanadores o al dulce Orfeo capaz de salvar de la muerte.
      • La figura de Cristo aparece vestido como cualquier otro personaje de la composición, con una simple túnica. Para distinguirlo del resto se le aplica un aumento ligero de su altura frente a sus discípulos y con gran desproporción frente a los pecadores (jerarquía de tamaño). El único objeto que constituye un atributo de su figura es un pergamino, que simboliza la ley mosaica y la nueva ley que surgirá con Cristo.

      • Desde el punto de vista estilístico, son muchos los rasgos bajo imperiales y del relieve plebeyo de la obra: la perspectiva jerárquica, la casi ausencia de espacio, la marcada isocefalia de los personajes, los rostros estereotipados de grandes ojos, las manos exageradamente grandes, los contornos duros a bisel... En definitiva, cuenta la expresividad más que la belleza formal.

      Más información sobre relieves e iconografía de los sarcófagos paleocristianos.

      Related news
      1. Curiosidades Zurdos
      2. Viaje Or Cuzco
      3. Viaje Preterite
      4. Curiosidades Legais
      5. How Often Do Lifestyle Condoms Break
      6. Like Lifestyle Brand
      7. Viaje Interprovincial Ecuador
      8. 40 Curiosidades De La Biblia
      9. Lifestyle 127
      10. Curiosidades Literarias
      11. Lifestyle Amrit Maan
      12. Lifestyle Kids
      13. Viaje Bruce Banner And The Hulk
      14. Lifestyle Pictures
      15. Viaje Leaded
      16. Viaje A Cancun
      17. Viaje Frases
      18. 69 Curiosidades De Dragon Ball
      19. Lifestyle Amrit Maan Lyrics
      20. Why Don'T We Curiosidades
      21. Viaje En El Tiempo Pelicula
      22. Lifestyle Homes
      23. Viaje Vs Viajar
      24. Viaje Que Es
      25. Curiosidades 2 Guerra
      26. Lifestyle Kids
      27. Lifestyle University
      28. Lifestyle 2020
      29. Viaje Del Heroe
      30. Curiosidades Two And A Half
      31. Curiosidades Zaragoza
      32. Lifestyle 360
      33. Lifestyle 8925 Home Gym
      34. Lifestyle 600
      35. Viaje Roman Candle
      36. Agencia De Viaje 002
      37. Lifestyle Products
      38. Lifestyle Motors
      39. Lifestyle Quotes
      40. Curiosidades Xalmimilulco
      41. Lifestyle Youtube Video Ideas
      42. Lifestyle Xquisit Chemnitz
      43. Lifestyle Lite
      44. Curiosidades Forrest Gump
      45. Viaje Oro Reserva
      46. Curiosidades 500 Dias Con Ella
      47. Viaje Y Hotel
      48. Lifestyle Watches
      49. Will Lifestyle Store In Delhi
      50. Lifestyle Garden Furniture
      51. Curiosidades Rusia
      52. Curiosidades Ucrania
      53. Lifestyle Insurance
      54. Lifestyle Garden Aruba
      55. Viaje 6 Meses Sudamerica
      56. Curiosidades 9
      57. Viaje Skull And Bones 2019
      58. Curiosidades Anne With An E
      59. Viaje Grecia
      60. Lifestyle 12 Series Ii System
      61. Viajes Quinto Sol
      62. Curiosidades Resident Evil
      63. Can Lifestyle Changes Reverse Coronary Heart Disease
      64. Lifestyle Blogs Like The Tig
      65. Lifestyle One
      66. Curiosidades De Chile
      67. Lifestyle Nutrition Menu
      68. Lifestyle Business
      69. Curiosidades Historicas
      70. To Lifestyle Factors
      71. Curiosidades Barcelona
      72. Lifestyle Brands
      73. Lifestyle Youtubers
      74. Curiosidades Vis A Vis
      75. Curiosidades Sobre Portugal
      76. Curiosidades The Circle Brasil
      77. Viaje Inmovil
      78. Lifestyle Definition
      79. Lifestyle 650 Home Entertainment System
      80. Lifestyle Block
      81. Curiosidades Sobre Portugal
      82. Curiosidades 80S
      83. Curiosidades Inuteis
      84. Curiosidades 8M
      85. Lifestyle 8925
      86. Viajes 60 Años Comunidad De Madrid
      87. How To Pronounce Viaje In Spanish
      88. Go Where Lifestyle
      89. How Lifestyle Affects Skin
      90. Lifecycle 9500R
      91. Viaje Hamaki
      92. Curiosidades Woodstock
      93. Viaje Koino Yokan
      94. Lifestyle 28 Bose
      95. Lifestyle Watches
      96. Viaje En Bus
      97. Curiosidades Wikipedia
      98. Lifestyle Apparel
      99. Lifestyle Thesaurus
      100. Curiosidades Finlandia
      101. When Lifestyle Variations Are Taken In Account
      102. Who Lifestyle Diseases
      103. Viaje 40 Años
      104. Curiosidades 8M
      105. Lifestyle Tattoo
      106. What Lifestyle Means
      107. Viaje 7 Tazas
      108. Curiosidades De La Naturaleza
      109. Curiosidades William Shakespeare
      110. Curiosidades 800
      111. Curiosidades 3M
      112. Viaje En Mt 03
      113. Is Lifestyle Christianity University Accredited
      114. Viaje Espacial
      115. Curiosidades 50 Sombras Liberadas
      116. Curiosidades Universo
      117. Will Lifestyle Online
      118. Lifestyle 600 System
      119. Lifestyle Kitchens
      Read More :- "LOS SARCÓFAGOS DE BETHESDA, EL MENSAJE PALEOCRISTIANO DE LA SALVACIÓN Y DEL TRIUNFO SOBRE LA MUERTE."

      Thursday 11 June 2020

      Hackable - Secret Hacker | Vulnerable Web Application Server

      Read More :- "Hackable - Secret Hacker | Vulnerable Web Application Server"

      CVE-2020-2655 JSSE Client Authentication 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 news
      1. Pentest Vs Ethical Hacking
      2. Hacker Forum
      3. Pentest Certification
      4. Hacker Code
      5. Pentest Jobs
      6. Hacker Tools
      7. Pentest Reporting Tool
      8. Pentest Ftp
      9. Hacker Types
      10. Pentest Bootcamp
      11. Pentest Gear
      12. Hacker Kevin Mitnick
      13. Pentest Process
      14. Pentest Devices
      15. Hacker Kevin Mitnick
      16. How To Pentest A Website
      17. Pentest Reporting Tool
      18. Pentesting Tools
      Read More :- "CVE-2020-2655 JSSE Client Authentication Bypass"