Post on 06-Oct-2020
ú
1´
´
$>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
¿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
#MundoCiberViejuno https://twitter.com/hashtag/MundoCiberViejuno
4
Historia de HTTP
5
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
HTTP 1.0
▪ 1996
▪ Propuesto por Tim Berners-Lee
▪ Soporte para:
▪ GET (como en la versión 0.9)
▪ HEAD
▪ POST
7
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
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
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
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
Evolución de las conexiones
12
¿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
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
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
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
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
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
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
Especificaciones de QUIC
Fuente: https://blog.cloudflare.com/http-3-from-root-to-tip20
Draft-ietf-quic-transport-25
• 22 de Enero de 2020
• https://tools.ietf.org/html/draft
-ietf-quic-transport-25
21
HTTP 3 vs HTTP 2
22
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
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
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
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
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
Demo de trama QUIC
28
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
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
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
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
Benchmark
https://github.com/audstanley/gQuicKcpTcpBenchmark
33
Uso y estandarización de QUIC
34
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
Google y Cloudflare lo están impulsando
36
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
QUICs por el mundo
• Actualmente la cabecera para utilizar HTTP/3 es Alt-Svc.
39
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
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
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
Demo de análisis en Chrome
43
Nuevos vectores de ataque
44
Un canal “oscuro” para la ocultación de ataques
IDS
45
Demo de evasión
46
Demo de evasión: 1) Bloqueo Eicar normal
47
Demo de evasión: 1) Evasión de Eicar a través de QUIC
48
Ejemplo de implementación
1
2
3
49
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
Demo de C2
51
Bloqueando QUIC en Google Chrome
52
Bloqueando QUIC en Palo Alto
Fuente: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC&lang=es
53
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
Bloqueando QUIC en Sophos
55
Segunda vía, bloqueando el puerto 443 por UDPPrimera vía, a través del Control de Aplicaciones:
Conclusiones
56
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
The End
@ZerolynxOficial@jantonioCalles
@jalcaldea
@1c3t0rm
@fluproject58