-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathindex.html
420 lines (375 loc) · 23 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
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="">
<meta name="author" content="">
<link rel="apple-touch-icon" sizes="180x180" href="media/img/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="media/img/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="media/img/favicon-16x16.png">
<link rel="manifest" href="media/img/site.webmanifest">
<meta name="theme-color" content="#ffffff">
<title>ALPACA Attack</title>
<link href="media/css/style.css" rel="stylesheet" type="text/css">
</head>
<body>
<header id="top">
<h1>ALPACA Attack</h1>
<div class="logo"></div>
</header>
<section id="intro">
<ul class="toc">
</li>
<li><a href="#paper">Paper</a>
</li>
<li><a href="#question-answer">Q&A</a></li>
<li><a href="libs.html">How to ALPN/SNI</a></li>
<li><a href="updates.html">Updates!</a></li>
</ul>
</section>
<section>
<h2>News</h2>
<ul>
<li>A big reevaluation of TLS libraries, TLS application servers, and a new internet scan by Jannik Hölling is now available in the <a href="updates.html">Updates</a> section!</li>
<li>ALPACA will be presented at <a
href="https://www.blackhat.com/us-21/briefings/schedule/index.html#alpaca-application-layer-protocol-confusion---analyzing-and-mitigating-cracks-in-tls-authentication-23522">Black
Hat USA 2021</a>,
<a href="https://www.usenix.org/conference/usenixsecurity21/presentation/brinkmann">USENIX Security Symposium
2021</a>, and
<a href="https://rwc.iacr.org/2022/program.php">Real Word Crypto Symposium 2022</a>!
</li>
<li>Recommended articles: <a
href="https://arstechnica.com/gadgets/2021/06/hackers-can-mess-with-https-connections-by-sending-data-to-your-email-server/">Ars
Technica</a> (Dan Goodin),
<a
href="https://www.golem.de/news/sicherheitsluecke-alpaca-angriff-zeigt-cross-protokoll-schwaeche-von-tls-2106-157143.html">Golem</a>
(Hanno Böck; German)</li>
</ul>
</ul>
<h2>Introduction</h2>
<p>TLS is an internet standard to secure the communication
between servers and clients on the internet, for example
that of web servers, FTP servers, and Email servers. This
is possible because TLS was designed to be application
layer independent, which allows its use in many diverse
communication protocols.
</p>
<p>ALPACA is an application layer protocol content confusion
attack, exploiting TLS servers implementing different
protocols but using compatible certificates, such as multi-domain
or wildcard certificates. Attackers can redirect traffic
from one subdomain to another, resulting in a valid TLS session.
This breaks the authentication of TLS and cross-protocol attacks
may be possible where the behavior of one protocol service may compromise
the other at the application layer.
</p>
<p>We investigate cross-protocol attacks on TLS in general and
conducted a systematic case study on web servers, redirecting HTTPS
requests from a victim's web browser to SMTP, IMAP, POP3, and FTP
servers. We show that in realistic scenarios, the attacker can
extract session cookies and other private user data or execute
arbitrary JavaScript in the context of the vulnerable web server,
therefore bypassing TLS and web application security.
</p>
<p>We evaluated the real-world attack surface of web browsers
and widely-deployed Email and FTP servers in lab experiments
and with internet-wide scans. We find that 1.4M web servers
are generally vulnerable to cross-protocol attacks, i.e., TLS
application data confusion is possible. Of these, 114k web servers
can be attacked using an exploitable application server. As a
countermeasure, we propose the use of the Application Layer Protocol
Negotiation (ALPN) and Server Name Indication (SNI) extensions in
TLS to prevent these and other cross-protocol attacks.
</p>
<p>Although this vulnerability is very situational and can be challenging
to exploit, there are some configurations that are exploitable
even by a pure web attacker. Furthermore, we could only analyze
a limited number of protocols, and other attack scenarios may exist.
Thus, we advise that administrators review their deployments and
that application developers (client and server) implement
countermeasures proactively for all protocols.
</p>
<h2>Attack Overview</h2>
<img src="media/img/alpaca-overview.png"></img>
<p>The image shows three possible ways for an attacker to use
cross-protocol attacks against webservers, exploiting vulnerable
FTP and Email servers: In the Upload Attack, the attacker exfiltrates authentication cookies or other private
data.
In the Download Attack, the attacker executes a stored XSS attack.
In the Reflection Attack, the attacker executes a reflected
XSS in the context of the victim website.
</p>
<h2 id="paper">Full Technical Paper (last update: 2021-06-09)</h2>
<p><a href="ALPACA.pdf">ALPACA: Application Layer Protocol
Confusion-Analyzing and Mitigating Cracks in TLS
Authentication</a>, Marcus Brinkmann, Christian Dresen, Robert
Merget, Damian Poddebniak, Jens Müller, Juraj Somorovsky, Jörg
Schwenk, Sebastian Schinzel.
</p>
<p>The artifacts are available at
<a href="https://github.com/RUB-NDS/alpaca-code/">GitHub</a>.</p>
<h2 id="question-answer">FAQ</h2>
<h3>I am an admin, should I drop everything and fix this?</h3>
<p>Probably not. For the ALPACA attack to succeed, many
preconditions need to be fulfilled. The generic attack
requires a MitM attacker that can intercept and divert the
victim's traffic at the TCP/IP layer. However, if you run
application servers such as FTP and email on non-standard
ports that are not blocked by browsers, you should make sure
that you are not vulnerable to the web attacker variant of
ALPACA that can affect users of Internet Explorer.</p>
<h3>What can the attackers gain?</h3>
<p>For the specific attacks on HTTPS described in the paper,
the attacker can potentially steal cookies or perform a cross-site
scripting attacks.</p>
<p>However, the potential consequences to the general ALPACA attack are
dependent on the interactions of two unknown protocols, so any number
of undesirable behaviors may be possible.
</p>
<h3>Who is vulnerable?</h3>
<p>This is difficult to answer. The general flaw behind ALPACA
is within the server authentication of TLS, so potentially all TLS servers
are affected that have compatible certificates with other TLS services.
In regards to that, all those servers have to be considered vulnerable.
However, for practical purposes, this definition is not very useful, as the
flaw is exploitable only in some cases. We therefore distinguish between
vulnerable servers and exploitable services. Our analysis was limited
to only a few protocols and a small number of implementations, so we
can really only make clear statements for those. From our analysis, the
following is generally true:</p>
<ul>
<li>Sharing certificates between a Webserver and an FTP server is almost
always dangerous if an attacker has write access to the FTP server.
It is sometimes dangerous if the attacker has no write access.</li>
<li>Sharing certificates between a Webserver and an SMTP/POP3/IMAP server
is sometimes dangerous, depending on the exact behavior of the server.</li>
</ul>
<p>Here is a list of analyzed implementations in regards to their vulnerability (see Table 3 in the paper):
Sendmail SMTP allowed reflection attacks that work in Internet Explorer when
used over STARTTLS. Cyrus, Kerio Connect and Zimbra IMAP servers allowed
download and reflection attacks that work in Internet Explorer. Courier,
Cyrus, Kerio Connect and Zimbra allowed download attacks that work in Internet Explorer. Microsoft IIS, vsftpd,
FileZilla Server and Serv-U FTP servers allowed reflection attacks that work in Internet Explorer. And the same
FTP servers allowed upload and download attacks that work in all browsers.</p>
<p>But even then there are interactions with analyzed and not yet analyzed
protocols which makes a risk estimation difficult, since we believe that
there is a large number of yet undiscovered vulnerabilities in this area.</p>
<p>Browsers are generally affected by the vulnerability, but they are not
responsible for the flaw. We found that some browsers are more vulnerable
than others because of how they react to non-HTTP responses.</p>
<h3>So how practical is the attack?</h3>
<p>Most attacks require an active Man-in-the-Middle attacker, that means some way
for an attacker to intercept and modify the data sent from the victim’s browser
to the web server. This is difficult on the Internet, but can be a plausible
attacker model on the local network. Also, some attack variations do not
require a Man-in-the-Browser, and thus are more dangerous. In particular,
if you are still using Internet Explorer, we recommend you update to the
latest version from June 8th, 2021.</p>
<h3>Is my website/ftp-server/mail-server vulnerable?</h3>
<p>It might be. If you are hosting several TLS-enabled application servers
on the same hostname, or if you use multi-domain certificates, or if you
use wild-card certificates, you may be vulnerable to the general
confusion attack. If one of the application servers you are hosting
has an exploitable upload, download, or reflection vector, this may
negatively impact the security of your webserver.</p>
<h3>Is my browser/client vulnerable?</h3>
<p>Internet Explorer and Edge Legacy (i.e., those <emph>not</emph> based on Chrome)
are "more" vulnerable than other browsers, because they block fewer ports and
perform content-sniffing. Content-sniffing is dangerous, because it enables
JavaScript code execution in server responses that are noisy due to error
messages by the application server that implements a protocol different
from HTTP. This means that the pure web attacker variant of ALPACA is more
dangerous for users of such browsers than for other users.</p>
<p>However, no browser protects the user against all possible ALPACA attacks.
In particular, all browsers can be compromised by a Man-in-the-Middle attacker
who has write-access to an error-tolerant FTP server presenting a certificate
compatible with a target web server under attack. Although the FTP server can
in theory protect against this particular attack by detecting HTTP POST requests
and/or terminating the connection after a small number of errors, this attack
variant shows that this is not a bug in the browser, the web server, or the
application server, but an emergent property of the TLS landscape.</p>
<h3>Is this a new attack?</h3>
<p>The ALPACA attack is not fundamentally new. Cross-protocol
attacks on HTTP were first described by Jochen Topf (2001),
and Jann Horn presented the first attack on a TLS-secured HTTP
connection in 2014 involving ProFTPD. We did the first systematic
study for cross-protocol attacks against the browser exploiting
popular SMTP, IMAP, POP3, and FTP servers, performed an
internet-wide scan to estimate the number of affected web
servers, and generalized the attack away from a browser-specific
issue to a general property of misconfigured TLS servers. We
think that this new perspective is useful in focussing countermeasures
on a limited number of effective options, rather than patching
application servers one at a time as more exploits are found.</p>
<h3>Why does TLS not protect the TCP connection endpoints?</h3>
<p>The ALPACA attack is only possible because TLS does not protect the source
or destination IP and port address of the TCP connection. As is stated
in the TLS RFC, TLS is application layer independent. However, this gap
in protection gives the attacker the flexibility to redirect traffic
from one server to another. If the presented certificate of the
substitute server is compatible with that of the intended server,
the general content confusion attack is possible (although it
depends on the server and client behavior if it can actually
be exploited).</p>
<h3>Can TLS mitigate these attacks at all?</h3>
<p>Two extensions in TLS can provide some protection to the application layer
protocol: SNI and ALPN. With SNI, the client can let the server know about
the hostname it wants to connect to, which is useful in virtual hosting
configurations. Sadly, SNI is often misconfigured with an insecure fallback
to a default server, allowing content confusion attacks (for HTTP, these
were analyzed by Delignat et al. in 2015, and Zhang et al. in 2020).
However, the SNI standard allows the server to terminate the connection
if the hostname does not match the expected hostname of the server,
which would prevent some ALPACA attacks in practice. Unfortunately,
this strict behavior is rarely implemented, even among web servers.</p>
<p>For application servers, which commonly lag behind web servers in
feature completeness with regards to TLS, the situation is even more
dire. With ALPN, the client can let the server know about the intended
protocol, which is used to demultiplex between HTTP/1.x and HTTP/2
connections to a web server without requiring an additional roundtrip.
Here the standard mandates strict behavior, so a server supporting ALPN
should terminate the connection if no supported protocol is requested
by the client. Unfortunately, this strict behavior is commonly not
implemented, and many application servers do not even support the ALPN extension
at all.</p>
<h3>Why is the attack called "ALPACA"?</h3>
<p>We initially were interested in special properties of the
HTTP, FTP and email protocols that make cross-protocols
practical. However, we eventually realized that the ALPACA
attack is generic, and that the authenticity of the TLS
connection is already compromised before any application
layer data is exchanged. So, the original acronym
("Application Layer Protocols Allowing Cross-Protocol Attacks")
was not a good fit anymore, because it is not the ALP allowing
the attack, but the insufficiency of TLS to protect the TCP
connection endpoints. Still, the name stuck, and we managed
to squeeze the letters in the title in the following way:
"Application Layer Protocol Confusion - Analyzing and mitigating
Cracks in tls Authentication". Tortured, we know.
But ALPACAs are still cute. :)</p>
<h3>How have vendors responded to this vulnerability?</h3>
<p>Many vendors have updated their application servers to remove exploitation
vectors or add countermeasures in the application layer and/or TLS implementation.
TLS library maintainers have reviewed the ALPN and SNI implementations and
updated their code and documentation to allow easy implementation of
countermeasures by developers. To prevent the attacks in the pure browser
attacker model, browser vendors have blocked more standard application ports
and disabled content-sniffing in more scenarios.</p>
<p>Specific responses are listed below (please contact us if you have more info!):</p>
<ul>
<li>Microsoft Internet Explorer blocked more non-HTTP server ports and disabled content sniffing for HTTP requests
to non-standard ports (<a
href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31971">CVE-2021-31971</a>).</li>
<li>
Sendmail fixed a bug to detect HTTP requests when STARTTLS is used, and since Sendmail 8.17 there are additional
countermeasures at the application layer to block HTTP requests.</li>
<li>Courier 5.1.0 implemented support for ALPN.</li>
<li>FileZilla implemented countermeasures at the application and TLS layer.</li>
<li>Vsftpd 3.0.4 implemented countermeasures at the application and TLS layer.</li>
<li>Nginx 1.21.0 implemented mitigations at the application layer in the mail proxy.</li>
<li>crypto/tls (Go) now <a
href="https://github.com/golang/go/commit/90d6bbbe42c15d444c1da0a1c293192d6f735a8e">enforces ALPN overlap</a>
when negotiated on both sides.</li>
</ul>
<h3>How is this attack related to other TLS attacks?</h3>
<p>ALPACA uses the same attacker scenario as other TLS attacks,
i.e. it assumes a Man-in-the-Middle attacker who can lure a
victim to an attacker-controlled web site. However, in the
ALPACA attack, we do not try to attack the cryptographic
protections of TLS directly. Instead, we exploit defects
in the configuration of TLS services, who often share
certificates to save costs, reduce administrative work,
or enable reverse proxy deployments where several services
share a single, terminating TCP endpoint. In contrast to other
TLS attacks, the attacker never compromises the confidentiality
of the TLS connection. However, due to misconfiguration,
authenticity and integrity are affected, allowing the attacker
to inject some dangerous data into the connection, while
the victim remains oblivious to the attack.</p>
<h3>What about other protocols?</h3>
<p>The ALPACA attack is generic, i.e. it describes the preconditions
under which TLS traffic from the client to one server implementing
one protocol can be redirected to another server implementing a
different protocol, which can lead to any number of undesirable
behavior or security vulnerabilities. We only looked at the
combination of a HTTP client with an SMTP, IMAP, POP3, or FTP
application server. We did not investigate any of the other
hundreds of possible cross-protocol scenarios possible with
current TLS enabled applications and servers. In addition,
as TLS is more widely deployed, more protocols will be added
to the TLS landscape, increasing the possibility of ALPACA
attacks quadratically with the number of protocols and applications.</p>
<p>If you find application layer protocol confusion attacks in other protocols,
let us know! We are of course very interested in hearing about other
affected protocols and applications.</p>
<h3>If my clients and servers verify the ALPN and SNI parameters of the TLS handshake, will I be secure against
this attack?</h3>
<p>We do not think that it is feasible for clients or servers to enforce
the use of ALPN and SNI for a long time, because doing so will exclude
legacy clients and servers that have not been updated yet, and it is
unlikely that this will be accepted by users or service providers.
However, if both client and server support ALPN, and make sure that
an acceptable protocol and hostname is negotiated, they will protect
connections to all other servers with compatible certificates by
the same client from almost all content confusion attacks.</p>
<p>However, there still is some room for content confusion attacks
even with ALPN and SNI fully deployed. If two services implement
the same protocol on the same host, but on a different port,
connections to one server can be redirected to another by an attacker.
This can enable same-protocol, same-host context confusion attacks
similar to those described by Delignat et al. (2015) and Zhang et al. (2020)
in very specific scenarios.</p>
<h3>Is this vulnerability really serious enough to deserve a name, a logo and a web page?</h3>
<p>ALPACA is not a simple software bug that can be fixed with an update
to a single library or component. Instead, clients and servers need
to be updated to protect the connections to other (seemingly unrelated)
servers. This means we need to raise awareness of the issue across all
TLS-enabled applications and protocols, which is a huge effort. We expect
that the general ALPACA attack will stay with us for many years, so we
have a cute animal to keep us company while we help clients and servers
to adopt the suggested countermeasures!</p>
<h3>How can I contact you?</h3>
<p>You can reach us via mail or twitter:</p>
<ul>
<li>Marcus Brinkmann, Ruhr University Bochum, <a href="https://twitter.com/lambdafu">@lambdafu</a>,
marcus.brinkmann@rub.de</li>
<li>Christian Dresen, Münster University of Applied Sciences, <a href="https://twitter.com/dr4ys3n">@dr4ys3n</a>,
c.dresen@fh-muenster.de</li>
<li>Robert Merget, Ruhr University Bochum, <a href="https://twitter.com/ic0nz1">@ic0nz1</a>, robert.merget@rub.de
</li>
<li>Damian Poddebniak, Münster University of Applied Sciences, <a href="https://twitter.com/dues__">@dues__</a>,
poddebniak@fh-muenster</li>
<li>Jens Müller, Ruhr University Bochum, <a href="https://twitter.com/jensvoid">@jensvoid</a>,
jens.a.mueller@rub.de</li>
<li>Juraj Somorovsky, Paderborn University, <a href="https://twitter.com/jurajsomorovsky">@jurajsomorovsky</a>,
juraj.somorovsky@upb.de</li>
<li>Jörg Schwenk, Ruhr University Bochum, <a href="https://twitter.com/JoergSchwenk">@JoergSchwenk</a>,
joerg.schwenk@rub.de</li>
<li>Sebastian Schinzel, Münster University of Applied Sciences, <a
href="https://twitter.com/seecurity">@seecurity</a>, schinzel@fh-muenster</li>
</ul>
<h3>Responsible Disclosure Timeline</h3>
<ul>
<li>2020-10-20: Initial contact with Eric Rescorla (author of TLS standard, CTO of Mozilla)</li>
<li>2020-12-03: Initial contact with OpenSSL.</li>
<li>2021-02-02: Initial contact with other TLS library maintainers.</li>
<li>2021-02-20: Initial contact with all affected application servers (FTP, Email).</li>
<li>2021-03-25: Initial contact with nginx and Apache.</li>
<li>2021-06-09: Public disclosure.</li>
</ul>
</section>
<footer>
<p class="text-muted">Last updated 2021-06-09. The ALPACA
website is free to use under
a <a href="//creativecommons.org/publicdomain/zero/1.0/">CC0</a>
license. Web design by <a href="http://sarahmadden.com/">Sarah
Madden</a> and Christian Dresen.
Adapted for Alpaca by Marcus Brinkmann.
The ALPACA logo was designed
by <a href="https://www.fiverr.com/tnhs_project">tnhs_project</a>.
| <a href="imprint.html">Imprint</a></p>
</footer>
</body>
</html>