![Page 1: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/1.jpg)
ú
1´
´
![Page 2: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/2.jpg)
$>Whoami
Jesús Alcalde
@jalcaldea
• Responsable de I+D+I de GRUPO ZEROLYNX
• Graduado en Ingeniería Informática e Ingeniería del Software por la URJC
• CEH v9, ITIL y nCSE
• Ponente en diversas CONs como RootedCON, EuskalHack, UAH, Techfest, Palomática, HTH, Hack&Beers, etc.
Juan Antonio Calles
@jantonioCalles
• CEO y Co-fundador de GRUPO ZEROLYNX
• Socio director de ciberseguridad de OSANE Consulting
• Doctor, doble postgrado e ingeniero en informática por la URJC. CISA, CHFI e ITIL
• Co-fundador de Flu Project y X1RedMasSegura
2
![Page 3: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/3.jpg)
¿Cómo ha evolucionado Internet de los 90 hasta hoy?
▪ 90’s – 2020: 360 a 4.000 millones de usuarios
▪ Abaratamiento de costes: ¡2000’s DSL para todos!
▪ Páginas que ayudaron a su evolución: Altavista (1995), Google(1996-1998), Hotmail (8,5 Millones de usuarios en 1997)…
3
![Page 4: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/4.jpg)
#MundoCiberViejuno https://twitter.com/hashtag/MundoCiberViejuno
4
![Page 5: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/5.jpg)
Historia de HTTP
5
![Page 6: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/6.jpg)
HTTP 0.9
▪ Hypertext Transfer Protocol (1991)
▪ World Wide Web Consortium e Internet EngineeringTask Force
▪ Permitía realizar únicamente peticiones GET a unservidor:▪ Petición: GET /index.html \r\n\r\n
▪ Respuesta HTML: <html>…</html>
▪ No soportaba cabeceras, ni peticiones POST
<html>
…
</html>
6
![Page 7: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/7.jpg)
HTTP 1.0
▪ 1996
▪ Propuesto por Tim Berners-Lee
▪ Soporte para:
▪ GET (como en la versión 0.9)
▪ HEAD
▪ POST
7
![Page 8: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/8.jpg)
HTTP 1.1
▪ 1999
▪ Soporte para Pipelining (múltiples peticiones ala vez por la misma conexión)
▪ Reduce los tiempos de cada peticióneliminando el RTT (Round-Trip delay)
▪ Versión plasmada en la RFC 2616
▪ Es la más utilizada en la actualidad
8
![Page 9: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/9.jpg)
HTTP 1.2
▪ 2000
▪ Proponía el protocolo PEP, diseñado en 1995(Protocolo de Extensión de Protocolo), parala extensión de aplicaciones
▪ Versión plasmada en la RFC 2774(experimental)
▪ https://www.w3.org/TR/WD-http-pep-951122
9
![Page 10: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/10.jpg)
HTTP 2
▪ 2012-2015. RFC 7540
▪ Basado en SPDY
▪ Compresión de cabeceras HPACK (elimina campos
redundantes)
▪ Multiplexación. Permite enviar y recibir varios
mensajes al mismo tiempo
10
![Page 11: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/11.jpg)
HTTP 3
▪ 2015
▪ Reemplazo de TCP por QUIC (Quick UDP Internet Connections)
▪ Diseñado por Google y soportado por Chrome, Opera, Facebook, …
▪ Aúna las mejores ideas de HTTP 2, TCP, UDP y TLS
▪ Se basa en UDP y TLS 1.3, aún más rápido y seguro
11
![Page 12: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/12.jpg)
Evolución de las conexiones
12
![Page 13: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/13.jpg)
¿Por qué hubo una evolución de las conexiones?
▪ Cables de mayor categorización (6A, 7…)
▪ Nuevos protocolos de conexiones inalámbricas con mayor
ancho de banda (2,4Ghz, 5Ghz…)
▪ Fibra óptica
▪ Por ello, los servicios de Internet podían permitir un mayor
consumo de información
13
![Page 14: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/14.jpg)
Mejoras en la capa de aplicación
▪ Primeras mejoras ligadas a la definición de HTML (1991: TimBerners-Lee, 1993: IETF)
▪ Permitían estructurar la información y pautas genéricas sobreestilos visuales
▪ Cambios destacables: Javascript (1995) y CSS (1996)
▪ Última revisión: HTML5 (2014).
14
![Page 15: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/15.jpg)
Mejoras a nivel de la protección de las comunicaciones
▪ Necesidad de seguridad (banca, estados…)
▪ 1992: HTTPS en Netscape Navigator, conSSL
▪ 2000: HTTPS adoptado como estándar(RFC 2818), con TLS
15
![Page 16: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/16.jpg)
Aunque hubo luces y sombras a nivel de cifrado
▪ “Beast” para SSL y TLS (CVE-2011-3389)
▪ “Crime” para TLS (CVE-2012-4929)
▪ “Heartbleed” para TLS (CVE-2014-0160)
▪ “Poodle” para SSL 3 (CVE-2014-3566)
▪ “Freak” para OpenSSL (CVE-2015-0204)
▪ “Logjam” para TLS (CVE-2015-4000)
16
![Page 17: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/17.jpg)
Mejoras en la capa de session con SPDY
• Google (2009), para mejorar el rendimiento
• Protocolo de nivel de sesión complementario a HTTP (sobre TCP/IP)
• Permitía flujos simultáneos por una sola conexión TCP
• Google (2015) anunció su fin en favor de HTTP 2
17
![Page 18: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/18.jpg)
Mejoras en la capa de aplicación y sesión con HTTP 2
• Basado en SPDY
• Multiplexación, compresión de las cabeceras (HPACK), etc.
• Servicio “cache push”: permitía al servidor enviar de antemanorecursos que el cliente va a necesitar en un futuro.
• A enero de 2020, un 42,7% de webs soportan este protocolo.
18
![Page 19: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/19.jpg)
Mejoras en la capa de transporte con QUIC
• Mejorar el rendimiento y la Seguridad con:
– TCP + TLS + HTTP/2 (pero sobre UDP)
• Mejoras destacables en las que ahora profundizaremos:
– Latencia de establecimiento de conexión
– Control de la congestión
– Multiplexado sin bloqueos
– Corrección de errores directa.
19
![Page 20: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/20.jpg)
Especificaciones de QUIC
Fuente: https://blog.cloudflare.com/http-3-from-root-to-tip20
![Page 21: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/21.jpg)
Draft-ietf-quic-transport-25
• 22 de Enero de 2020
• https://tools.ietf.org/html/draft
-ietf-quic-transport-25
21
![Page 22: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/22.jpg)
HTTP 3 vs HTTP 2
22
![Page 23: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/23.jpg)
Comparativa
• QUIC aúna las mejores soluciones de HTTP, TLS y TCP, con la sencillez de UDP
• La mejora en rendimiento de HTTP sobre QUIC como método de transporte, en comparación con HTTP 2 es reseñable.
23
![Page 24: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/24.jpg)
Establecimiento de conexión
• En la 1ª conexión QUIC, el cliente realiza un intercambio de mensajes enviando unmensaje “hello” (CHLO) vacío y el servidor envía un rechazo (REJ) con el token y loscertificados
• Las próximas veces que el cliente envíe un CHLO, usa las credenciales cacheadas paracomunicarse de forma cifrada, estableciendo una sesión en 0 RTT
• Resuelve varios problemas de UDP:
– IP Spoofing: el servidor envía un token que contiene la IP del cliente y una marca temporal delservidor. Mientras la IP no varíe o el token no caduque, éste será válido
– Ataques de Replay: es solventado mediante el envío de un número aleatorio (nonce) junto conla derivación de las claves, al igual que lo hace TLS
24
![Page 25: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/25.jpg)
Autenticación, cifrado de las cabeceras y carga útil de un paquete
• Los paquetes de QUIC se encuentran siempre
cifrados, menos algunas partes de las
cabeceras
• Solamente los paquetes PUBLIC_RESET, cuya
función es resetear una conexión, no están
autenticados. Impidiendo inyecciones y
manipulaciones
25
![Page 26: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/26.jpg)
Corrección de errores y pérdida de paquetes
• Al ser UDP, no existe un control del flujo, lo que posibilita lapérdida o desorden de paquetes
• Para recuperar estos paquetes utiliza un esquema de “ForwardError Correction” (FEC)
• Si uno de los paquetes del grupo se pierde, el contenido de estese puede recuperar mediante el análisis del paquete FEC y delresto de paquetes del grupo
404Packet Not
Found
26
![Page 27: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/27.jpg)
Migración de conexión
• Gran capacidad de resiliencia a cambios de IP y acambios de traducciones de NAT durante eltranscurso de la sesión
• Es debido a que las conexiones están identificadaspor un ID de conexión de 64 bits, generado de formaaleatoria por el cliente y el cual continúa siendo igualdurante estas migraciones
27
![Page 28: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/28.jpg)
Demo de trama QUIC
28
![Page 29: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/29.jpg)
Versiones QUIC
Version Owner Version Owner Version Owner
0x00000000 n/a 0x5130343[0-9] Google 0x91c170[0-255] quicly
0x?a?a?a?a IETF 0x5130353[0-9] Google 0xabcd000[0-f] Microsoft
0x454747[00-ff] NetApp 0x51303939 Google 0xf10000[00-ff] IETF
0x50435130 Private Octopus 0x5430343[8-9] Google 0xf123f0c[0-f] Mozilla
0x5130303[1-9] Google 0x5430353[0-9] Google 0xfaceb00[0-f] Facebook
0x5130313[0-9] Google 0x54303939 Google 0xff[000000-ffffff] IETF
0x5130323[0-9] Google 0x50524f58 Google 0xf0f0f0f[0-f] ETH Zürich
0x5130333[0-9] Google 0x51474f[0-255] quic-go 0xf0f0f1f[0-f] Telecom Italia
29
![Page 30: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/30.jpg)
QUIC Payload
• Un paquete de QUIC tras quitar las cabeceras de seguridad está formado por distintas secuencias.
• Al menos contendrá una trama identificando el tipo de la misma y sus campos.
Frame 1
Frame 2
Frame N
…
Frame Type (i)
Type-Dependent Fields (*)
Generic Frame Layout
QUIC Payload
30
![Page 31: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/31.jpg)
Tipos de trama
Type Value Frame Type Name
0x00 PADDING
0x01 PING
0x02 – 0x03 ACK
0x04 RESET_STREAM
0x05 STOP_SENDING
0x06 CRYPTO
0x07 NEW_TOKEN
0x08 – 0x0f STREAM
0x10 MAX_DATA
Type Value Frame Type Name
0x11 MAX_STREAM_DATA
0x12 – 0x13 MAX_STREAMS
0x14 DATA_BLOCK
0x15 STREAM_DATA_BLOCKED
0x16 – 0x17 STREAMS_BLOCKED
0x18 NEW_CONNECTION_ID
0x19 RETIRE_CONNECTION_ID
0x1a PATH_CHALLENGE
0x1b PATH_RESPONSE
0x1c – 0x1d CONNECTION_CLOSE
31
![Page 32: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/32.jpg)
Tipos de flujo
Stream ID (Bits) Stream Type
0x0 Client-Initiated, Bidirectional
0x1 Server-Initiated, Bidirectional
0x2 Client-Initiated, Unidirectional
0x3 Server-Initiated, Unidirectional
• Los flujos de datos de QUICpueden ser unidireccionales obidireccionales.
• Los últimos dos bits de unStream ID nos permiteidentificar el tipo de flujoutilizado.
• De esta forma QUIC alfuncionar sobre UDP, QUIC seencargará de recuperar elpaquete en caso de que sepierda alguno
32
![Page 33: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/33.jpg)
Benchmark
https://github.com/audstanley/gQuicKcpTcpBenchmark
33
![Page 34: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/34.jpg)
Uso y estandarización de QUIC
34
![Page 35: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/35.jpg)
Implementación y soporte de QUIC en los distintos navegadores
• Open source (promovido por Google)
• Se encuentra en Chromium, sobre el que se basan la
mayoría de los navegadores actuales.
• Más del 70% de la navegación se lleva a cabo con
navegadores que soportan QUIC
35
![Page 36: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/36.jpg)
Google y Cloudflare lo están impulsando
36
![Page 37: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/37.jpg)
Estandarización del uso
• Actualmente solo un 2,8% de losservicios web hacen uso delprotocolo QUIC.
• Aunque es un hecho que las grandescompañías de Internet apoyan el usoe implantación (Cloudflare, Akamai,
Google, Facebook, …)https://w3techs.com/technologies/details/ce-quic
37
![Page 39: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/39.jpg)
QUICs por el mundo
• Actualmente la cabecera para utilizar HTTP/3 es Alt-Svc.
39
![Page 40: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/40.jpg)
Cómo analizar tráfico QUIC
• NetworkMiner, Fiddler, Cain&Abel, Packet Analyzer, etc. aún no
soportan este protocolo, dificultando las tareas de inspección
• Wireshark: implementado por el equipo que impulsó HTTP sobre
QUIC (Alexis La Goutte).
• Los analistas de seguridad tenemos que desarrollar nuestros
scripts para analizar QUIC
40
![Page 41: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/41.jpg)
Curl y Libcurl
• Para poder usar curl con QUIC es
necesario tener instalada la librería de
HTTP/3 (quiche) y los últimos git clones de
curl.
• Libcurl permite el uso de HTTP/3
estableciendo correctamente el bit
CURLOPT_H3 en la API.
41
![Page 42: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/42.jpg)
Uso de QUIC en Google Chrome
• Dentro de las herramientas de tráfico de
red de Chrome, en chrome://net-export/
• Para la inspección de las sesiones QUIC
puede utilizarse “catapult netlog viewer”
tanto en local como online:
https://netlog-viewer.appspot.com/#quic
42
![Page 43: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/43.jpg)
Demo de análisis en Chrome
43
![Page 44: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/44.jpg)
Nuevos vectores de ataque
44
![Page 45: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/45.jpg)
Un canal “oscuro” para la ocultación de ataques
IDS
45
![Page 46: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/46.jpg)
Demo de evasión
46
![Page 47: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/47.jpg)
Demo de evasión: 1) Bloqueo Eicar normal
47
![Page 48: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/48.jpg)
Demo de evasión: 1) Evasión de Eicar a través de QUIC
48
![Page 49: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/49.jpg)
Ejemplo de implementación
1
2
3
49
![Page 50: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/50.jpg)
Command & Control con Merlin
IDS
• C2 escrito en Golang que puede usarse tantoen QUIC como HTTP/2
• Desplegamos el servidor:./merlinServer-Linux-x64 -proto hq -psk L3t5v1s1tFlu
• Desplegamos el agente:./merlinAgent-Linux-x64 -proto hq -psk L3t5v1s1tFlu
• https://github.com/Ne0nd0g/merlin
50
![Page 51: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/51.jpg)
Demo de C2
51
![Page 52: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/52.jpg)
Bloqueando QUIC en Google Chrome
52
![Page 53: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/53.jpg)
Bloqueando QUIC en Palo Alto
Fuente: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC&lang=es
53
![Page 54: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/54.jpg)
Bloqueando QUIC en Fortinet
3) Tras los cambios, los navegadores Google Chrome severán obligados a utilizar TLS en lugar de QUIC.
Fuente: https://kb.fortinet.com/kb/viewContent.do?externalId=FD36529
1) Crear un service-object "QUIC" especificando el puertoUDP/443.
2)Crear una política que niegue el tráfico QUIC de la redinterna hacia Internet. Esta política debería situarse en laparte superior.
54
![Page 55: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/55.jpg)
Bloqueando QUIC en Sophos
55
Segunda vía, bloqueando el puerto 443 por UDPPrimera vía, a través del Control de Aplicaciones:
![Page 56: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/56.jpg)
Conclusiones
56
![Page 57: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/57.jpg)
Conclusiones y lecciones aprendidas
• La compatibilidad comienza a no ser un problema.
• Los navegadores ya soportan QUIC, lo que deriva en un escenario opaco queposibilita la evasión de medidas de seguridad.
• Todavía existen pocas implementaciones sobre QUIC y pocas utilidades anivel de seguridad (AV, FW, IDS, etc.).
• Y por si no os había quedado claro… HTTP/3 ha llegado para quedarse.
57
![Page 58: $>Whoami - Zerolynx · •Multiplexación, compresión de las cabeceras (HPACK), etc. •Servicio “cachepush”: permitía al servidor enviar de antemano recursos que el cliente](https://reader034.vdocumento.com/reader034/viewer/2022051812/602ff203d8a7e34f2b6bd44b/html5/thumbnails/58.jpg)
The End
@ZerolynxOficial@jantonioCalles
@jalcaldea
@1c3t0rm
@fluproject58