forked from vanhoefm/krackattacks
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
389 lines (320 loc) · 39.8 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" class="no-js">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>KRACK Attacks: Breaking WPA2</title>
<meta name="keywords" content="WPA2, KRACK, key reinstallation, security protocols, network security, attacks, nonce reuse, handshake, packet number, initialization vector, Mathy Vanhoef" />
<meta name="description" content="Este sitio presenta el Ataque de Reinstalación de clave (KRACK) [Español]. Rompe el protocolo WPA2 forzando la reutilización de nonce en los algoritmos de cifrado utilizados por Wi-Fi." />
<link href="css/default.css" rel="stylesheet" type="text/css" media="all" />
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<script type="text/javascript" src="js/jquery.min.js"></script>
<script type="text/javascript" src="js/modernizr.min.js"></script>
<!--[if lt IE 9]>
<script src="js/respond.src.js"></script>
<![endif]-->
<!-- Global site tag (gtag.js) - Google Analytics -->
<script async src="https://www.googletagmanager.com/gtag/js?id=UA-35642360-3"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'UA-35642360-3');
</script>
</head>
<body>
<div id="wrapper">
<div id="header-wrapper">
<div id="header" class="container">
<div id="logo">
<img src="images/logo-small.png" width="100%"/>
</div>
<div id="title">
<h1><b>K</b>ey <b>R</b>einstallation <b>A</b>tta<b>ck</b>s</h1>
<h2>Rompiendo WPA2 forzando la reutilización del nonce</h2>
<h3>Descubierto por <a href="https://twitter.com/vanhoefm">Mathy Vanhoef</a> e <a href="https://distrinet.cs.kuleuven.be/">imec-DistriNet</a>, KU Leuven. <br/><i>Traducido al español por <a href="https://twitter.com/carlosmart7104">Carlos Martínez</a></i></h3>
</div>
</div>
</div>
<div id="menu-wrapper">
<div id="main-nav" class="container">
<span class="custom-mobile-menu-title" style="display: none;">Nagivate page</span>
<ul class="menu">
<li class="page_item"><a href="#intro">Intro</a></li>
<li class="page_item"><a href="#demo">Demo</a></li>
<li class="page_item"><a href="#details">Detalles</a></li>
<li class="page_item"><a href="#paper">Paper</a></li>
<li class="page_item"><a href="#tools">Tools</a></li>
<li class="page_item"><a href="#faq">Q&A</a></li>
</ul>
</div>
</div>
<div id="page" class="container">
<div id="content">
<!-------------------- INTRO -------------------->
<a name="intro" ></a>
<h2 class="firsttitle">Introducción</h2>
<p>Descubrimos serias debilidades en WPA2, el protocolo que asegura todas las redes Wi-Fi protegidas modernas.
Un atacante dentro del alcance de una víctima puede explotar estas debilidades usando <u>k</u>ey <u>r</u>einstallation <u>a</u>tta<u>ck</u>s (KRACKs).
Concretamente, los atacantes pueden usar esta nueva técnica de ataque para leer información que previamente se suponía que estaba cifrada de forma segura.
Esto se puede abusar para robar información confidencial, como números de tarjetas de crédito, contraseñas, mensajes de chat, correos electrónicos, fotos, etc.
<strong>El ataque funciona contra todas las redes Wi-Fi protegidas modernas</strong>.
Dependiendo de la configuración de la red, también es posible inyectar y manipular datos.
Por ejemplo, un atacante podría inyectar ransomware u otro malware en sitios web.</p>
<p>Las debilidades están en el estándar Wi-Fi en sí, y no en productos individuales o implementaciones.
Por lo tanto, es probable que se vea afectada cualquier implementación correcta de WPA2.
Para evitar el ataque, los usuarios deben actualizar los productos afectados tan pronto como las actualizaciones de seguridad estén disponibles.
Tenga en cuenta que <strong>si su dispositivo es compatible con Wi-Fi, lo más probable es que se vea afectado</strong>.
Durante nuestra investigación inicial, descubrimos que Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys y otros, se ven afectados por alguna variante de los ataques.
For more information about specific products, consult the <a href="https://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4">database of CERT/CC</a>, or contact your vendor.</p>
<p>Para obtener más información sobre productos específicos, consulte la <a href="https://acmccs.github.io/session-F3/">conferencia de seguridad de computadoras y comunicaciones (CCS)</a> , y en la <a href="https://www.blackhat.com/eu-17/briefings/schedule/#key-reinstallation-attacks-breaking-the-wpa2-protocol-8861">Black Hat Europe</a> conference. Nuestro <a href="#paper">documento de investigación detallado</a> ya se puede descargar.</p>
<!-------------------- DEMO -------------------->
<a name="demo" ></a>
<h2>Demonstración</h2>
<p>Como prueba de concepto, ejecutamos un ataque clave de reinstalación contra un teléfono inteligente Android.
En esta demostración, el atacante puede descifrar todos los datos que transmite la víctima.
Para un atacante, esto es fácil de lograr, porque nuestro ataque de reinstalación clave es excepcionalmente devastador contra Linux y Android 6.0 o superior.
Esto es porque <strong>Android y Linux pueden engañarse para (re) instalar una clave de cifrado totalmente en ceros</strong> (<a href="#details-android">ver más abajo para más información</a>).
Al atacar a otros dispositivos, es más difícil descifrar todos los paquetes, aunque se puede descifrar un gran número de paquetes.
En cualquier caso, la siguiente demostración destaca el tipo de información que un atacante puede obtener al realizar ataques de reinstalación de claves contra redes de Wi-Fi protegidas:
</p>
<div class="demo-video">
<div class="demo-video-container">
<iframe width="853" height="480" src="https://www.youtube-nocookie.com/embed/Oh4WURZoR98?rel=0&showinfo=0&vq=hd720" frameborder="0" allowfullscreen></iframe>
</div>
</div>
<p>Nuestro ataque no se limita a recuperar credenciales de inicio de sesión (es decir, direcciones de correo electrónico y contraseñas).
En general, cualquier dato o información que la víctima transmita puede descifrarse. Además, según el dispositivo utilizado y la configuración de la red, también es posible descifrar los datos enviados a la víctima (por ejemplo, el contenido de un sitio web).
Aunque los sitios web o las aplicaciones pueden usar HTTPS como una capa adicional de protección, le advertimos que esta protección extra puede (todavía) pasarse por alto en un número preocupante de situaciones.
<!-- https://docs.google.com/spreadsheets/d/1t5GXwjw82SyunALVJb2w0zi3FoLRIkfGPc7AMjRF0r4/edit#gid=1053404143 -->
Por ejemplo, HTTPS se omitió anteriormente en <a href="https://pdfs.semanticscholar.org/48fc/8f1aa0b6d1e4266b8017820ff8770fb67b6f.pdf">non-browser software</a>,
en <a href="https://www.imperialviolet.org/2014/02/22/applebug.html">iOS y OS X de Apple</a>,
en <a href="https://arstechnica.com/information-technology/2015/04/android-apps-still-suffer-game-over-https-defects-7-months-later/">Android apps</a>,
en <a href="https://arxiv.org/ftp/arxiv/papers/1505/1505.00589.pdf">Android apps nuevamente</a>,
en <a href="http://blog.ioactive.com/2014/01/personal-banking-apps-leak-info-through.html">aplicaciones bancarias</a>,
e incluso en <a href="https://arstechnica.com/information-technology/2017/01/majority-of-android-vpns-cant-be-trusted-to-make-users-more-secure/">aplicaciones VPN</a>.
</p>
<!-------------------- DETAILS -------------------->
<a name="details" ></a>
<h2>Detalles</h2>
<!-- TODO: So far, this 14-year-old handshake has remained free from attacks, and is even proven secure. However, we show that the 4-way handshake is vulnerable to a key reinstallation attack -->
<p>Nuestro ataque principal es contra el handshake (saludo de manos) de 4 vías del protocolo WPA2.
Este apretón de manos se ejecuta cuando un cliente desea unirse a una red Wi-Fi protegida, y se utiliza para confirmar que tanto el cliente como el punto de acceso poseen las credenciales correctas (por ejemplo, la contraseña precompartida de la red). Al mismo tiempo, el saludo de 4 vías también negocia una nueva clave de cifrado que se utilizará para cifrar todo el tráfico subsiguiente. Actualmente, todas las redes Wi-Fi protegidas modernas utilizan el protocolo de enlace de 4 vías. Esto implica que todas estas redes se ven afectadas por (alguna variante de) nuestro ataque.
Por ejemplo, el ataque funciona contra redes Wi-Fi personales y empresariales, contra el WPA anterior y el último estándar WPA2, e incluso contra redes que solo usan AES.
<!-- TODO: flow -->
<strong> Todos nuestros ataques contra WPA2 usan una técnica novedosa llamada ataque de reinstalación clave (KRACK):</strong></p>
<h3>Ataques clave de reinstalación: descripción de alto nivel</h3>
<p>En un ataque de reinstalación clave, el adversario engaña a una víctima para que vuelva a instalar una clave que ya está en uso. Esto se logra<strong> manipulando y reproduciendo mensajes criptográficos de comunicación</strong>.
Cuando la víctima reinstala la clave, los parámetros asociados, como el número de paquete de transmisión incremental (es decir, nonce) y el número de paquete de recepción (es decir, el contador de reproducción) se restablecen a su valor inicial. Básicamente, para garantizar la seguridad, una clave solo debe instalarse y usarse una vez. Desafortunadamente, encontramos que esto no está garantizado por el protocolo WPA2. Al manipular los apretones de manos criptográficos, podemos abusar de esta debilidad en la práctica.</p>
<h3>Ataques clave de reinstalación: ejemplo concreto contra el apretón de manos de 4 vías</h3>
<p>Como se describe en la <a href="#paper">introducción del documento de investigación</a>, la idea detrás de un ataque clave de reinstalación se puede resumir de la siguiente manera. Cuando un cliente se une a una red, ejecuta el enlace de 4 vías para negociar una nueva clave de cifrado. Instalará esta tecla después de recibir el mensaje 3 del apretón de manos de 4 vías. Una vez que se instala la clave, se usará para cifrar los marcos de datos normales utilizando un protocolo de encriptación. Sin embargo, como los mensajes se pueden perder o descartar, el Punto de acceso (AP) retransmitirá el mensaje 3 si no recibió una respuesta apropiada como acuse de recibo. Como resultado, el cliente puede recibir el mensaje 3 varias veces. Cada vez que recibe este mensaje, reinstalará la misma clave de cifrado y, por lo tanto, reiniciará el número de paquete de transmisión incremental (nonce) y recibirá el contador de reproducción utilizado por el protocolo de cifrado. Mostramos que <strong>un atacante puede forzar estos restablecimientos nonce recolectando y reproduciendo retransmisiones del mensaje 3 del saludo de 4 vías</strong>.
Al forzar la reutilización del nonce de esta manera, el protocolo de encriptación puede ser atacado, por ejemplo, los paquetes pueden ser reproducidos, descifrados y / o forjados. La misma técnica también se puede utilizar para atacar a la clave de grupo, PeerKey, TDLS, y rápido enlace de transición BSS.</p>
<!-- TODO: Once we also made a presentation, we can include a diagram / figure describing the attack -->
<h3>Impacto practico</h3>
<p>En nuestra opinión, el ataque más extendido y prácticamente impactante es el ataque de reinstalación clave contra el apretón de manos de 4 vías.
Basamos este juicio en dos observaciones.
Primero, durante nuestra propia investigación encontramos que la mayoría de los clientes se vieron afectados por ella.
En segundo lugar, los adversarios pueden usar este ataque para descifrar los paquetes enviados por los clientes, lo que les permite interceptar información confidencial, como contraseñas o cookies. El descifrado de paquetes es posible porque un ataque de reinstalación de clave hace que los números de transmisión (a veces también denominados números de paquete o vectores de inicialización) se restablezcan a cero. Como resultado, <strong>se usa la misma clave de cifrado con valores nonce que ya se han usado en el pasado</strong>.
A su vez, esto hace que todos los protocolos de encriptación de WPA2 reutilicen el <a href="https://en.wikipedia.org/wiki/Keystream">flujo de claves</a> al encriptar los paquetes.
En caso de que un mensaje que reutilice el flujo de claves tenga contenido conocido, se vuelve trivial derivar el flujo de claves usado. Este flujo de claves se puede usar para descifrar mensajes con el mismo valor. Cuando no hay contenido conocido, es más difícil descifrar paquetes, aunque aún es posible en varios casos (por ejemplo, <a href="https://crypto.stackexchange.com/a/2250">el texto en inglés todavía se puede descifrar</a>).
<!-- TODO: We can mention encrypted message 4's are usefull for this? -->
En la práctica, encontrar paquetes con contenido conocido no es un problema, por lo que se debe suponer que cualquier paquete puede descifrarse.
</p>
<p>La capacidad de descifrar paquetes puede usarse para descifrar TCP SYN paquetes. Esto permite a un adversario obtener los números de secuencia TCP de una conexión y <a href="https://en.wikipedia.org/wiki/TCP_sequence_prediction_attack"> secuestrar las conexiones TCP</a>.
Como resultado, aunque se usa WPA2, el adversario ahora puede realizar uno de los ataques más comunes contra redes Wi-Fi abiertas: inyectar datos maliciosos en conexiones HTTP no cifradas. Por ejemplo, un atacante puede abusar de esto para inyectar ransomware o malware en sitios web que la víctima está visitando.</p>
<p>Si la víctima usa el protocolo de cifrado WPA-TKIP o GCMP, en lugar de AES-CCMP, el impacto es especialmente catastrófico.
<b>Contra estos protocolos de encriptación, la reutilización de nonce permite a un adversario no solo descifrar, sino también forjar e inyectar paquetes</b>.
Además, debido a que GCMP utiliza la misma clave de autenticación en ambas direcciones de comunicación, y esta clave se puede recuperar si los números se reutilizan, se ve especialmente afectada. Tenga en cuenta que la compatibilidad con GCMP se está actualizando con el nombre Wireless Gigabit (WiGig), y se espera que se <a href="http://www.grandviewresearch.com/press-release/global-wireless-gigabit-wigig-market">adopte a un ritmo elevado</a> en los próximos años.</p>
<p>La dirección en la que los paquetes pueden descifrarse (y posiblemente forjarse) depende del apretón de manos que se está atacando. Simplificado, al atacar el enlace de 4 vías, podemos descifrar (y forjar) los paquetes enviados por el cliente. Al atacar el apretón de manos de Fast BSS Transition (FT), podemos descifrar (y forjar) los paquetes enviados al cliente. Finalmente, la mayoría de nuestros ataques también permiten la reproducción de tramas unidifusión, difusión y multidifusión. Para más detalles, consulte la Sección 6 de <a href="#paper">nuestro trabajo de investigación </a>.</p>
<p>Tenga en cuenta que nuestros ataques <b>no recuperan la contraseña de la red Wi-Fi</b>. Tampoco recuperan (ninguna parte de) la nueva clave de cifrado que se negocia durante el apretón de manos de 4 vías.</p>
<a name="details-android" ></a>
<h3>Android y Linux</h3>
<p>Nuestro ataque es especialmente catastrófico contra la versión 2.4 y superior de wpa_supplicant, un cliente Wi-Fi comúnmente usado en Linux.
Aquí, el cliente instalará una clave de cifrado totalmente cero en lugar de reinstalar la clave real. Esta vulnerabilidad parece ser causada por un comentario en el estándar Wi-Fi que sugiere borrar la clave de cifrado de la memoria una vez que se instaló por primera vez.
Cuando el cliente recibe ahora un mensaje retransmitido 3 del saludo de 4 vías, volverá a instalar la clave de cifrado ahora borrada, instalando efectivamente una clave de cero. Como Android usa wpa_supplicant, Android 6.0 y superior también contiene esta vulnerabilidad. Esto hace que sea <strong>trivial interceptar y manipular el tráfico enviado por estos dispositivos Linux y Android </strong>.
<!-- TODO: Should double-check that carries don't mess with the wpa_supplicant version... -->
Tenga en cuenta que actualmente el <a href="https://developer.android.com/about/dashboards/index.html">41% de los dispositivos Android</a> son vulnerables a esta variante excepcionalmente devastadora de nuestro ataque.</p>
<h3>Identificadores CVE Asignados</h3>
<p>Se asignaron los siguientes identificadores y vulnerabilidades comunes (CVE, por sus siglas en inglés) para rastrear qué productos se ven afectados por instancias específicas de nuestro ataque de reinstalación clave:</p>
<ul>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13077">CVE-2017-13077</a>: Reinstalación de la clave de encriptación pairwise (PTK-TK) en el enlace de 4 vías.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13078">CVE-2017-13078</a>: Reinstalación de la clave de grupo (GTK) en el enlace de 4 vías.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13079">CVE-2017-13079</a>: Reinstalación de la clave del grupo de integridad (IGTK) en el enlace de 4 vías.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13080">CVE-2017-13080</a>: Reinstalación de la clave de grupo (GTK) en el apretón de manos de grupo.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13081">CVE-2017-13081</a>: Reinstalación de la clave de grupo de integridad (IGTK) en el apretón de manos de grupo.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13082">CVE-2017-13082</a>: aceptación de una solicitud de reasignación de transición rápida de BSS (FT) y reinstalación de la clave de cifrado por parejas (PTK-TK) mientras la procesa.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13084">CVE-2017-13084</a>: Reinstalación de la tecla STK en el apretón de manos PeerKey.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13086">CVE-2017-13086</a>: reinstalación de la clave de configuración de enlace directo Tunneled (TDLS) PeerKey (TPK) en el apretón de manos TDLS.</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13087">CVE-2017-13087</a>: reinstalación de la clave de grupo (GTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).</li>
<li><a href="https://nvd.nist.gov/vuln/detail/CVE-2017-13088">CVE-2017-13088</a>: reinstalación de la clave de grupo de integridad (IGTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).</li>
</ul>
<p>Tenga en cuenta que cada identificador de CVE representa una instanciación específica de un ataque de reinstalación de clave. Esto significa que cada ID de CVE describe una vulnerabilidad de protocolo específica y, por lo tanto, <b>muchos proveedores se ven afectados por cada ID de CVE individual </b>. También puede leer la <a href="https://www.kb.cert.org/vuls/id/228519">nota de vulnerabilidad VU # 228519</a>de CERT / CC para obtener detalles adicionales sobre qué productos se sabe que están afectados.</p>
<p></p>
<!-------------------- PAPER -------------------->
<a name="paper" ></a>
<h2>Paper</h2>
<!-- TODO: Put our slides here as well, once I finished them -->
<p>Nuestro documento de investigación detrás del ataque se titula <a href="https://papers.mathyvanhoef.com/ccs2017.pdf">Ataques de reinstalación clave: Forzar la reutilización de elementos no utilizados en WPA2</a> y se presentará en la <a href="https://www.sigsac.org/ccs/CCS2017/">conferencia sobre seguridad informática y comunicaciones (CCS)</a> el <a href="https://acmccs.github.io/session-F3/">miércoles 1 de noviembre de 2017</a>.
<p>Aunque este documento se hizo público ahora, ya se presentó para su revisión el 19 de mayo de 2017. Después de esto, solo se hicieron cambios menores. Como resultado, los hallazgos en el documento ya tienen varios meses. Mientras tanto, hemos encontrado técnicas más fáciles para llevar a cabo nuestro ataque de reinstalación clave contra el apretón de manos de 4 vías. Con nuestra novedosa técnica de ataque, ahora es trivial explotar implementaciones que solo aceptan retransmisiones encriptadas del mensaje 3 del apretón de manos de 4 vías. En particular, esto significa que <strong>atacar a macOS y OpenBSD es significativamente más fácil de lo que se describe en el artículo</strong>.</p>
<p>Nos gustaría resaltar los siguientes addendums y erratas:</p>
<h3>Apéndice: wpa_supplicant v2.6 y Android 6.0+</h3>
<p>El wpa_supplicant v2.6 de Linux también es vulnerable a la instalación de una clave de cifrado totalmente cero en el protocolo de enlace de 4 vías.
Esto fue descubierto por John A. Van Boxtel.
Como resultado, todas las versiones de Android superiores a 6.0 también se ven afectadas por el ataque y, por lo tanto, pueden engañarse para instalar una clave de cifrado totalmente cero.
El nuevo ataque funciona inyectando un mensaje forjado 1, con el mismo ANonce que se usó en el mensaje original 1, antes de reenviar el mensaje retransmitido 3 a la víctima.
<!-- TODO: !!! Include more information about the cause and workings of this attack !!! -->
</p>
<h3>Apéndice: otros apretones de manos vulnerables</h3>
<p>Después de nuestra investigación inicial como se informó en el documento, descubrimos que el apretón de manos TDLS y la trama de respuesta en modo de suspensión de WNM también son vulnerables a los ataques de reinstalación de claves.</p>
<h3>Erratas seleccionadas</h3>
<ul>
<li>En la Figura 9 en la etapa 3 del ataque, la trama transmitida desde el adversario al autenticador debería decir un ReassoReq en lugar de ReassoResp.</li>
</ul>
<!-------------------- Tools -------------------->
<a name="tools"></a>
<h2>Tools</h2>
<p>Hemos realizado secuencias de comandos para detectar si una implementación del apretón de manos de 4 vías, el apretón de llaves de grupo o el apretón de manos de transición rápida (FT) es vulnerable a los ataques de reinstalación de claves.
Estas secuencias de comandos se lanzarán una vez que hayamos tenido tiempo de limpiar sus instrucciones de uso.</p>
<p>También realizamos un script de prueba de concepto que explota la instalación de la llave (re) all-zero presente en ciertos dispositivos Android y Linux.
Este script es el que usamos en el <a href="#demo">video de demostración </a>.
Será lanzado una vez que todos tengan una posibilidad razonable de actualizar sus dispositivos (y hemos tenido la oportunidad de preparar el repositorio de códigos para su lanzamiento).
Observamos que la fiabilidad de nuestro script de prueba de concepto puede depender de cuán cerca esté la víctima de la red real.
Si la víctima está muy cerca de la red real, la secuencia de comandos puede fallar porque la víctima siempre se comunicará directamente con la red real, incluso si la víctima está (forzada) en un canal de Wi-Fi diferente a esta red.
</p>
<!-------------------- Q&A -------------------->
<a name="faq" ></a>
<h2>Preguntas y respuestas</h2>
<h3 class="firsttitle">¿Necesitamos ahora WPA3?</h3>
<p>No, afortunadamente las <strong>implementaciones pueden parchearse en una forma compatible con versiones anteriores</strong>. Esto significa que un cliente parcheado puede comunicarse con un punto de acceso sin parcheo, y viceversa.
En otras palabras, un cliente o puntos de acceso parcheado envía exactamente los mismos mensajes de apretón de manos que antes, y exactamente en los mismos momentos en el tiempo.
Sin embargo, las actualizaciones de seguridad asegurarán que una clave solo se instala una vez, evitando nuestros ataques. De nuevo, actualice todos sus dispositivos una vez que las actualizaciones de seguridad estén disponibles.</p>
<a name="changepw" ></a>
<h3>¿Debo cambiar mi contraseña de Wi-Fi?</h3>
<p>Cambiar la contraseña de su red Wi-Fi no impide (o atenúa) el ataque. Por lo tanto, no tiene que actualizar la contraseña de su red Wi-Fi. En su lugar, debe asegurarse de que todos sus dispositivos estén actualizados, y también debe actualizar el firmware de su enrutador. Después de actualizar su enrutador, puede <i>opcionalmente</i>cambiar la contraseña de Wi-Fi como precaución adicional.</p>
<h3>Estoy usando WPA2 con solo AES. ¿Eso también es vulnerable?</h3>
<p>Sí, esa configuración de red también es vulnerable. El ataque funciona contra WPA1 y WPA2, contra redes personales y empresariales, y contra cualquier conjunto de cifrado que se use (WPA-TKIP, AES-CCMP y GCMP). ¡Entonces todos deben actualizar sus dispositivos para evitar el ataque!</p>
<h3>Usas la palabra "nosotros" en este sitio web. ¿Quienes somos nosotros?</h3>
<p>Utilizo la palabra "nosotros" porque eso es lo que estoy acostumbrado a escribir en los documentos. En la práctica, todo el trabajo lo hago yo, siendo yo Mathy Vanhoef. Mi impresionante supervisor se agrega bajo una <a href="https://en.wikipedia.org/wiki/Academic_authorship#Honorary_authorship"> autoría honorífica</a> al trabajo de investigación por su excelente orientación general.
Pero todo el trabajo real se hizo por mi cuenta. Entonces, la <a href="http://phdcomics.com/comics.php?f=562">lista de documentos académicos del autor</a> no representa la <a href="https://imgur.com/a/mKnnu">división del trabajo</a> :)</p>
<h3>¿Es mi dispositivo vulnerable?</h3>
<p>Probablemente. Cualquier dispositivo que use Wi-Fi es probablemente vulnerable. Póngase en contacto con su proveedor para obtener más información.</p>
<h3>¿Qué sucede si no hay actualizaciones de seguridad para mi enrutador?</h3>
<!-- Note: there might be implementations bugs where replay of msg4/4 causes a key reinstallation attack -->
<p>Nuestro ataque principal está en contra del apretón de manos de 4 vías, y no explota los puntos de acceso, sino que se dirige a los clientes. Por lo tanto, es posible que su enrutador no requiera actualizaciones de seguridad. Le recomendamos encarecidamente que contacte a su proveedor para obtener más detalles. Sin embargo, en general, puede intentar mitigar los ataques contra enrutadores y puntos de acceso deshabilitando la funcionalidad del cliente (que se utiliza, por ejemplo, en los modos de repetidor) y deshabilitando 802.11r (roaming rápido). Para los usuarios habituales del hogar, su prioridad debe ser la actualización de clientes, como computadoras portátiles y teléfonos inteligentes.</p>
<h3>¿Cómo descubriste estas vulnerabilidades?</h3>
<p>Cuando trabajé en la versión final (es decir, preparada para la cámara) de <a href="https://lirias.kuleuven.be/bitstream/123456789/572634/1/asiaccs2017.pdf">otro artículo</a>, estaba revisando dos reclamaciones que hicimos sobre la implementación de OpenBSD del enlace de 4 vías. En cierto sentido, estaba desfalleciendo, porque se suponía que debía estar terminando el trabajo, en lugar de mirar el código. Pero allí estaba yo, inspeccionando un código que ya leí cien veces, para evitar tener que trabajar en el próximo párrafo. Fue en ese momento cuando una llamada particular a <a href="https://github.com/openbsd/src/blob/ca7fda7e2ae9fcf15b882d71bc910143e6b0d09b/sys/net80211/ieee80211_pae_input.c#L519">ic_set_key</a> me llamó la atención. Esta función se invoca al procesar el mensaje 3 del saludo de 4 vías, e instala la clave de par al controlador. Mientras miraba esa línea de código pensé <i>”Ha. Me pregunto qué pasa si esa función se llama dos veces”</i>. En el momento en que (correctamente) adiviné que llamarlo dos veces podría restablecer los nonces asociados a la tecla. Y dado que el mensaje 3 puede ser retransmitido por el punto de acceso, en la práctica podría llamarse de hecho dos veces. <i>“Es mejor hacer una nota de eso. Otros proveedores también pueden llamar a esa función dos veces. Pero terminemos primero este artículo ... ”</i>. Unas semanas más tarde, después de terminar el trabajo y completar otro trabajo, investigué esta nueva idea con más detalle. Y el resto es historia.</p>
<h3>El saludo de 4 vías fue matemáticamente probado como seguro. ¿Cómo es posible tu ataque?</h3>
<p>La breve respuesta es que la prueba formal no asegura que una llave se instale una vez. En su lugar, solo garantiza que la clave negociada permanezca en secreto, y que los mensajes de saludo no se pueden falsificar.</p>
<p>La respuesta más larga se menciona en la <a href="#paper">introducción de nuestro trabajo de investigación</a>: : nuestros ataques no violan las propiedades de seguridad probadas en el análisis formal del apretón de manos de 4 vías.
En particular, estas pruebas indican que la clave de cifrado negociada sigue siendo privada, y que se confirma la identidad tanto del cliente como del punto de acceso (AP).
Nuestros ataques no pierden la clave de cifrado.
Además, aunque los marcos de datos normales se pueden falsificar si se usa TKIP o GCMP, un atacante no puede forjar mensajes de enlace y, por lo tanto, no puede suplantar al cliente o AP durante los apretones de manos.
Por lo tanto, las propiedades que se probaron en el análisis formal del apretón de manos de 4 vías siguen siendo verdaderas.
Sin embargo, el problema es que las pruebas no modelan la instalación de la clave.
Dicho de otra manera, los modelos formales no definían cuándo debía instalarse una llave negociada.
En la práctica, esto significa que la misma clave se puede instalar varias veces, restableciendo así los contadores de no repetición y repetición utilizados por el protocolo de cifrado (por ejemplo, mediante WPA-TKIP o AES-CCMP).</p>
<h3>Algunos ataques en papel parecen difíciles</h3>
<p>Tenemos un trabajo de seguimiento que hace que nuestros ataques (contra macOS y OpenBSD) sean significativamente más generales y fáciles de ejecutar.
Entonces, aunque estamos de acuerdo en que algunos de los escenarios de ataque en el documento son poco prácticos, no permitas que esto te engañe para creer que los ataques clave de reinstalación no se pueden abusar en la práctica.</p>
<h3>¿La gente está explotando esto en la naturaleza?</h3>
<p>No estamos en condiciones de determinar si esta vulnerabilidad ha sido (o está siendo) explotada activamente en la naturaleza.
Dicho esto, las reinstalaciones clave pueden ocurrir espontáneamente sin que haya un adversario presente.
Esto puede suceder, por ejemplo, si se pierde el último mensaje de un apretón de manos debido al ruido de fondo, lo que provoca una retransmisión del mensaje anterior.
Al procesar este mensaje retransmitido, las claves pueden volver a instalarse, lo que resulta en una reutilización del mismo como en un ataque real.</p>
<h3>¿Debería usar temporalmente WEP hasta que mis dispositivos estén parcheados?</h3>
<p><strong>¡NO!</strong> Siga usando WPA2.</p>
<h3>¿Se actualizará el estándar Wi-Fi para abordar esto?</h3>
<p>Parece que hay un acuerdo de que el estándar Wi-Fi debe actualizarse para evitar explícitamente nuestros ataques. Es probable que estas actualizaciones sean compatibles con versiones anteriores con implementaciones anteriores de WPA2. El tiempo dirá si y cómo se actualizará el estándar.</p>
<h3>¿La Alianza Wi-Fi también aborda estas vulnerabilidades?</h3>
<p>Para aquellos que no están familiarizados con Wi-Fi, <a href="https://en.wikipedia.org/wiki/Wi-Fi_Alliance">Wi-Fi Alliance</a> es una organización que certifica que los dispositivos Wi-Fi cumplen con ciertos estándares de interoperabilidad. Entre otras cosas, esto garantiza que los productos Wi-Fi de diferentes proveedores funcionen bien juntos.</p>
<p><a href="https://www.wi-fi.org/securityupdate2017">Wi-Fi Alliance tiene un plan</a> para ayudar a remediar las vulnerabilidades descubiertas en WPA2. Resumiendo, ellos:</p>
<ul>
<li>Exigir pruebas para esta vulnerabilidad dentro de su red de laboratorio de certificación global.</li>
<li>Proporcione una herramienta de detección de vulnerabilidades para usar por cualquier miembro de Wi-Fi Alliance (esta herramienta se basa en mi propia herramienta de detección que determina si un dispositivo es vulnerable a algunos de los ataques de reinstalación de llaves descubiertos).</li>
<li>Comunique ampliamente los detalles sobre esta vulnerabilidad, incluidos los remedios, a los proveedores de dispositivos. Además, se recomienda a los vendedores que trabajen con sus proveedores de soluciones para integrar rápidamente los parches necesarios.</li>
<li>Comunique la importancia de que los usuarios se aseguren de que han instalado las últimas actualizaciones de seguridad recomendadas por los fabricantes de dispositivos.</li>
</ul>
<h3>¿Por qué utilizaste match.com como ejemplo en el video de demostración?</h3>
<p>Los usuarios comparten mucha información personal en sitios web como match.com. Por lo tanto, este ejemplo resalta toda la información sensible que un atacante puede obtener, y es de esperar que con este ejemplo las personas también se den cuenta mejor del impacto potencial (personal). También esperamos que este ejemplo haga que las personas conozcan <a href="https://www.theguardian.com/technology/2017/sep/26/tinder-personal-data-dating-app-messages-hacked-sold"> toda la información que estos sitios web de citas pueden recopilar</a>.</p>
<h3>¿Cómo se pueden prevenir estos tipos de errores?</h3>
<p>Necesitamos más inspecciones rigurosas de implementaciones de protocolos. ¡Esto requiere ayuda e investigación adicional de la comunidad académica! Junto con otros investigadores, esperamos organizar talleres para mejorar y verificar la corrección de las implementaciones del protocolo de seguridad.</p>
<h3>¿Por qué el nombre de dominio krackattacks.com?</h3>
<p>En primer lugar, soy consciente de que los ataques KRACK son <a href="https://en.wikipedia.org/wiki/Pleonasm">pleonasmos</a>, ya que KRACK significa <u>k</u>ey <u>r</u>einstallation <u>a</u>tta<u>ck</u> y, por lo tanto, ya contiene la palabra ataque. Pero el nombre de dominio rima, por eso se usa.
<h3>¿Recibió recompensas de errores por esto?</h3>
<p>Aún no he solicitado ninguna recompensa por errores, ni he recibido ninguna.</p>
<h3>¿Cómo se compara este ataque con otros ataques contra WPA2?</h3>
<p>Este es el primer ataque contra el protocolo WPA2 que no se basa en adivinar la contraseña. De hecho, otros ataques contra la red habilitada para WPA2 están en contra de las tecnologías circundantes, como <a href="http://archive.hack.lu/2014/Hacklu2014_offline_bruteforce_attack_on_wps.pdf">Wi-Fi Protected Setup (WPS)</a>, o son ataques contra estándares anteriores como <a href="https://lirias.kuleuven.be/bitstream/123456789/401042/1/wpatkip.pdf">WPA-TKIP</a>. Dicho de otra manera, ninguno de los ataques existentes estaba en contra del apretón de manos de 4 vías o en contra de los paquetes de cifrado definidos en el protocolo WPA2. En contraste, nuestro ataque de reinstalación clave contra el apretón de manos de 4 vías (y contra otros apretones de manos) resalta las vulnerabilidades en el protocolo WPA2.</p>
<h3>¿Otros protocolos también se ven afectados por los ataques de reinstalación de claves?</h3>
<p>Esperamos que ciertas <em>implementaciones de otros protocolos</em> sean vulnerables a ataques similares. Por lo tanto, es una buena idea auditar las implementaciones del protocolo de seguridad con este ataque en mente. Sin embargo, consideramos que es improbable que otros estándares de protocolo se vean afectados por ataques similares (o al menos así lo esperamos). Sin embargo, ¡todavía es una buena idea auditar otros protocolos!</p>
<h3>Hay una versión de mayor resolución del logotipo?</h3>
<p><a href="images/logo.png">Si hay</a>. ¡Y muchas gracias a la persona que hizo el logo!</p>
<h3>¿Cuándo notificó por primera vez a los proveedores sobre la vulnerabilidad?</h3>
<p>Enviamos notificaciones a proveedores cuyos productos probamos a nosotros mismos alrededor del 14 de julio de 2017. Luego de comunicarnos con estos proveedores, nos dimos cuenta de cuán generalizadas son las debilidades que descubrimos (solo entonces <em>realmente</em> me convencí de que era de hecho una debilidad del protocolo y no un conjunto de Errores de implementación). En ese momento, decidimos dejar que <a href="https://cert.org/">CERT/CC</a> ayudara con la divulgación de las vulnerabilidades. A su vez, el CERT / CC envió una amplia notificación a los vendedores el 28 de agosto de 2017.</p>
<h3>¿Por qué OpenBSD lanzó silenciosamente un parche antes del embargo?</h3>
<p>OpenBSD fue notificado de la vulnerabilidad el 15 de julio de 2017, antes de que CERT / CC estuviera involucrado en la coordinación. Muy rápidamente, Theo de Raadt respondió y criticó la fecha límite de divulgación tentativa: <i>“En el mundo de código abierto, si una persona escribe un diff y tiene que sentarse durante un mes, eso es muy desalentador”</i>. Tenga en cuenta que escribí e incluyé un diff sugerido para OpenBSD ya, y que en ese momento la fecha límite de divulgación tentativa era hacia fines de agosto. Como compromiso, les permití parchear en silencio la vulnerabilidad. En retrospectiva, esta fue una mala decisión, ya que otros podrían redescubrir la vulnerabilidad mediante la inspección de su parche silencioso. Para evitar este problema en el futuro, OpenBSD ahora recibirá notificaciones de vulnerabilidad más cerca del final de un embargo.</p>
<h3>¿Entonces esperas encontrar otras vulnerabilidades de Wi-Fi?</h3>
<p><i>“Creo que recién estamos comenzando”</i> — Master Chief, Halo 1</p>
<!-------------------- END OF MAIN CONTENT -------------------->
<div type="margin: 0px auto;">
</div>
</div>
</div>
</div>
<div id="copyright" class="container">
<p><a rel="license" href="http://creativecommons.org/licenses/by/4.0/" style="letter-spacing: normal;">
Creative Commons Attribution 4.0 International License</a> | Design inspired by <a href="http://templated.co" rel="nofollow">TEMPLATED</a>.</p>
</div>
<script type="text/javascript">
/**
* Mobile Menu
*/
(function ($) {
function close_menu() {
$('a#menu_button').removeClass('responsive-toggle-open');
$('#menu_title').css('background', '');
// So menu still works after being used, and window is resized
$('.js #main-nav .menu').removeAttr('style');
}
var current = $('span.custom-mobile-menu-title').html();
$('#main-nav').append('<a id="menu_button"></a>');
$('#main-nav').prepend('<div id="menu_title">' + current + '</div>');
$('a#menu_button, #menu_title').click(function (e) {
e.stopPropagation();
$('#menu_title').css('background', '#008C9A');
$('.js #main-nav .menu').slideToggle(function () {
if ($(this).is(':visible')) {
$('a#menu_button').addClass('responsive-toggle-open');
}
else {
close_menu();
}
});
});
// Close the mobile menu when clicked outside of it.
$('html').click(function () {
// Check if the menu is open, close in that case.
if ($('a#menu_button').hasClass('responsive-toggle-open')) {
$('.js #main-nav .menu').slideToggle(function () {
close_menu();
});
}
});
// Catch click events outside menu on iOS: https://gist.github.com/danott/855078
Modernizr.addTest('ipad', function () {
return !!navigator.userAgent.match(/iPad/i);
});
Modernizr.addTest('iphone', function () {
return !!navigator.userAgent.match(/iPhone/i);
});
Modernizr.addTest('ipod', function () {
return !!navigator.userAgent.match(/iPod/i);
});
Modernizr.addTest('appleios', function () {
return (Modernizr.ipad || Modernizr.ipod || Modernizr.iphone);
});
if (Modernizr.appleios) {
$("html").addClass("clickable");
}
})(jQuery);
</script>
</body>
</html>