WEBVTT

00:00:00.000 --> 00:00:03.730
[Translated by {Iikka}{Yli-Kuivila}
(ITKST56 course assignment at JYU.FI)]

00:00:03.730 --> 00:00:31.339
<i>33C3 preroll music</i>

00:00:31.339 --> 00:00:35.200
Herald: Welcome back to the festival
stage, still day two according to my

00:00:35.200 --> 00:00:40.970
clock, even though I have lost all sense
of time by now, I don't know. It's like a

00:00:40.970 --> 00:00:45.440
kind of rush year with so many great
talks, and we'll have the next super

00:00:45.440 --> 00:00:52.640
awesome talk held by Jiska, Gerbert and
Matthias. And those three lovely people

00:00:52.640 --> 00:00:59.780
will be showing us something about VPNs.
So-called very pwnable networks and why

00:00:59.780 --> 00:01:05.989
your VPN might not be as secure as you
think or have been led to believe. And

00:01:05.989 --> 00:01:10.909
this is not only important for the people
that think like, haha, I'm behind seven

00:01:10.909 --> 00:01:15.829
proxies. You can't catch me. But also,
maybe if your employer says, please use

00:01:15.829 --> 00:01:21.179
this VPN client and there might be some
surprises waiting for you. And this is

00:01:21.179 --> 00:01:26.350
again, a pre-recording, and afterwards I
can already see them here in our tools,

00:01:26.350 --> 00:01:32.490
but afterwards we will do a Q&amp;A session.
So if you have any questions, put them

00:01:32.490 --> 00:01:40.859
into the IRC or on Twitter or Mastodon
with the hashtag #rc3cwtv. And our lovely

00:01:40.859 --> 00:01:46.366
Signal Angel will collect them and we'll
see each other after the pre-recording.

00:01:46.366 --> 00:01:48.459
Jiska: Everyone and welcome to the talk

00:01:48.459 --> 00:01:56.170
Very Pwnable Network which is by Gerbert,
Matthias and me. So how did all start?

00:01:56.170 --> 00:02:02.369
Well, I got a little bit paranoid last
year and I just thought it might be a good

00:02:02.369 --> 00:02:08.510
idea to encrypt a lot because Wi-Fi, LTE,
TLS it might be intercepted, might be

00:02:08.510 --> 00:02:14.420
decrypted. So we should encrypt like
everyone is watching and so I should use a

00:02:14.420 --> 00:02:20.110
VPN on top. And then the next trust
assumption was that I connect to my

00:02:20.110 --> 00:02:26.740
university's network every day, so I
should trust this one anyway. And if I

00:02:26.740 --> 00:02:30.710
trust this network, then I could also use
this network and their professional VPN

00:02:30.710 --> 00:02:36.060
service. I hear you laughing, I hear
laughing but so this was my idea because

00:02:36.060 --> 00:02:42.570
then there is no additional thing that I
trust during my network activity. And

00:02:42.570 --> 00:02:47.610
well, they had this nice AnyConnect line
that just works on all operating systems.

00:02:47.610 --> 00:02:53.250
So it also sounds like a great product
name for a secure product like AnyConnect.

00:02:53.250 --> 00:03:00.180
Yeah. And then I started using this on my
mobile devices, right? And then suddenly I

00:03:00.180 --> 00:03:06.440
got crash logs and it looked like this. So
I mean, if you're paranoid, you obviously

00:03:06.440 --> 00:03:11.840
look into your crash logs every two days
and one of these crash logs was this one.

00:03:11.840 --> 00:03:17.170
It didn't really look nice the address
looks a bit strange, and you also have

00:03:17.170 --> 00:03:21.850
some trace of the crashed thread. And if
you log this into IDA and do a little bit

00:03:21.850 --> 00:03:25.540
of reverse engineering, you can also add
some function names in the AnyConnect

00:03:25.540 --> 00:03:31.540
extension, the AC extension and the crash
is somewhere when it applies VPN config

00:03:31.540 --> 00:03:37.160
somewhere in the - in the tunnel buffers.
I don't know. So - and then also, the

00:03:37.160 --> 00:03:44.220
address looks strange because the address
is IP version four backwards and then a

00:03:44.220 --> 00:03:52.020
few days later I got another crash and
this crash read like 68k New Line. And so

00:03:52.020 --> 00:03:56.670
it really looked like some configuration
strings that were crashing at certain

00:03:56.670 --> 00:04:02.110
addresses, so it really didn't look good.
But I also didn't have that much time. So

00:04:02.110 --> 00:04:06.940
I just wrote Cisco and said, like, so do
you mean to serious like, is your client

00:04:06.940 --> 00:04:13.180
really crashing that often? Because every
time I do my laundry, I have bad Internet

00:04:13.180 --> 00:04:20.370
connectivity, so my any - my AnyConnect
client starts to crash at weird addresses.

00:04:20.370 --> 00:04:26.889
And while this is like an issue for code
execution, the other issue is that if you

00:04:26.889 --> 00:04:30.950
just jam a few packets over the air, then
an attacker might be able to disconnect

00:04:30.950 --> 00:04:38.360
the victim from a VPN. So that is also an
issue. So because the AnyConnect client is

00:04:38.360 --> 00:04:44.010
not properly included in the operating
system iOS, and that means that you would

00:04:44.010 --> 00:04:48.130
just reconnect and send your messages in
plaintext over the network and the user

00:04:48.130 --> 00:04:52.440
does not get any notification. It's just a
VPN symbol that has gone and all traffic

00:04:52.440 --> 00:04:58.030
is sent in plaintext. And I wanted to
analyze this a little bit further and

00:04:58.030 --> 00:05:01.590
there is a debugging option in the
AnyConnect client. But since it's in the

00:05:01.590 --> 00:05:07.480
client that crashes, the logs are just
gone. If you have a crash and even worse

00:05:07.480 --> 00:05:12.340
also the operating system crash logs in
iOS are missing if you have the debugging

00:05:12.340 --> 00:05:19.180
option enabled. And well they answered:
"We cannot reproduce this". I mean,

00:05:19.180 --> 00:05:23.520
obviously they didn't help me with my
laundry or anything so they could not

00:05:23.520 --> 00:05:30.230
reproduce. And even worse, they ignored
the ticket for a long time until we said

00:05:30.230 --> 00:05:37.100
we are going to present this at this
year's CCC congress. And then 10 days

00:05:37.100 --> 00:05:40.520
before the talk they claimed that they had
fixed two out of the three crashes and

00:05:40.520 --> 00:05:44.400
were asking if we could reproduce the
crashes or not. But just a day before they

00:05:44.400 --> 00:05:51.510
said like they were not sure and so on. So
it was really a weird ticket there and I

00:05:51.510 --> 00:05:55.040
have no idea if things are fixed or not,
because to reproduce, I obviously need

00:05:55.040 --> 00:05:59.949
like tinfoil. I need like a couple of
smart phones with the AnyConnect client

00:05:59.949 --> 00:06:04.250
installed, and then I need to walk around
and hope that the Internet connection

00:06:04.250 --> 00:06:08.060
breaks and that it breaks in a way that
produces a crash. So this is just way too

00:06:08.060 --> 00:06:17.030
random. I also told Apple and Apple just
said, Well, the issue is that the client

00:06:17.030 --> 00:06:21.590
crashes so it's not really their
department, even though it's the network

00:06:21.590 --> 00:06:28.840
extension that crashes. So it's not their
task here to notify the user. It's just

00:06:28.840 --> 00:06:33.300
the VPN that is gone. And then you send
data in plaintext and this is all right.

00:06:33.300 --> 00:06:41.170
This is the expected behavior. So I got a
bit annoyed and stopped using VPNs, but I

00:06:41.170 --> 00:06:47.240
also had the idea to find students who
might look into this. And well, you know

00:06:47.240 --> 00:06:52.369
what happens when you find very motivated
students, they find vulnerabilities. And

00:06:52.369 --> 00:06:54.590
this is what this talk is going to be
about.

00:06:54.590 --> 00:06:59.930
Gerbert: So we had a look at the Cisco
AnyConnect client for Linux and found some

00:06:59.930 --> 00:07:04.460
interesting things. Shortly after
publishing our findings, several news

00:07:04.460 --> 00:07:09.929
articles popped up. But what happened
between the crashes of Jiska and these

00:07:09.929 --> 00:07:17.810
articles? VPN is interesting because it is
such an old research topic. However, the

00:07:17.810 --> 00:07:23.110
importance of the technology was later
increased by the corona pandemic. Many

00:07:23.110 --> 00:07:29.639
companies had to relocate to home offices
to meet the safety measures. VPN allows

00:07:29.639 --> 00:07:36.240
users from outside to access internal
resources of the company or university. To

00:07:36.240 --> 00:07:42.690
connect to a VPN server, additional client
software is usually required. Besides open

00:07:42.690 --> 00:07:49.020
source products, such as openVPN, a lot
of closed source software is offered on

00:07:49.020 --> 00:07:55.400
the market. Especially in the enterprise
sector. The users are forced to trust this

00:07:55.400 --> 00:08:01.930
software, install a black box in their
system in order to connect to a network.

00:08:01.930 --> 00:08:09.009
AnyConnect secure mobility client from
Cisco is an enterprise software solution.

00:08:09.009 --> 00:08:13.650
AnyConnect can be classified as a remote
access client that allows end-users to

00:08:13.650 --> 00:08:21.550
connect to a network that supports SSL VPN
and also IPsec. When using SSL VPN the

00:08:21.550 --> 00:08:29.510
authentication and the establishment of a
VPN tunnel is carried out via an SSL or

00:08:29.510 --> 00:08:35.650
TLS tunnel. The software acts as a fat
client that communicates with the VPN

00:08:35.650 --> 00:08:42.329
server via HTTPS. As already mentioned the
source code for AnyConnect is not publicly

00:08:42.329 --> 00:08:48.500
available. The application is distributed
with compiled binaries and libraries.

00:08:48.500 --> 00:08:54.210
Although the application is documented, it
does not cover internal functionality.

00:08:54.210 --> 00:08:59.160
Even the vulnerability disclosures, which
are published in public advisories, do not

00:08:59.160 --> 00:09:04.630
go into much technical detail. Therefore
there is only limited knowledge about the

00:09:04.630 --> 00:09:10.890
application and its internal behavior. We
have set ourselves the goal to examine

00:09:10.890 --> 00:09:19.649
AnyConnect for Linux and iOS in a recent
version. The main functionality of

00:09:19.649 --> 00:09:25.380
AnyConnect is the establishment of VPN
connections, but this is only the tip of

00:09:25.380 --> 00:09:31.680
the iceberg. AnyConnect also connects
numerous other features, to name a few:

00:09:31.680 --> 00:09:37.230
The distribution and execution of scripts
on host systems, automatically updating

00:09:37.230 --> 00:09:43.470
the software without asking the user for
permission. Another feature is host scan:

00:09:43.470 --> 00:09:49.310
it does not integrate into AnyConnect, but
it is considered as a standalone software.

00:09:49.310 --> 00:09:54.180
It works together with the AnyConnect
infrastructure and makes it possible to

00:09:54.180 --> 00:10:00.550
read out extensive system information of
the host and transmit them to VPN server.

00:10:00.550 --> 00:10:08.870
The related work of AnyConnect is based on
Cisco's public advisories and blog entries

00:10:08.870 --> 00:10:14.660
from certain security researchers.
Therefore, we decided to list and

00:10:14.660 --> 00:10:21.470
categorize all vulnerabilities since 2011.
On this diagram, we see a list of

00:10:21.470 --> 00:10:27.430
vulnerabilities per year, ordered by
severity. Most of the time reported

00:10:27.430 --> 00:10:33.290
vulnerabilities are classified as medium,
but even critical vulnerabilities were

00:10:33.290 --> 00:10:44.010
disclosed in 2011 and 2012. The increased
numbers in 2015 and 2016 caused numerous

00:10:44.010 --> 00:10:51.380
vulnerabilities of libraries such as
OpenSSL. The vulnerabilities were then

00:10:51.380 --> 00:10:57.420
divided into categories and illustrated in
the diagram. Cryptographic vulnerabilities

00:10:57.420 --> 00:11:04.370
are the most common as AnyConnect uses
OpenSSL and vulnerabilities in OpenSSL are

00:11:04.370 --> 00:11:10.050
also vulnerabilities in AnyConnect.
However, excluding the third-party

00:11:10.050 --> 00:11:15.770
vulnerabilities, the category of most
vulnerabilities affecting AnyConnect would

00:11:15.770 --> 00:11:21.510
be privilege escalations. Closely followed
by denial of service attacks, which are

00:11:21.510 --> 00:11:26.110
often directed against the running
application in order to disrupt the VPN

00:11:26.110 --> 00:11:33.110
connection. Overflow vulnerabilities or
version downgrades

00:11:33.110 --> 00:11:37.920
These results gave us a little insight
about the flaws of the past.

00:11:37.920 --> 00:11:43.279
Matthias: So before we will pass over to
the reversing parts, we want to give you a

00:11:43.279 --> 00:11:50.540
quick experience report regarding Cisco's
licensing support. Cisco ASA is a typical

00:11:50.540 --> 00:11:55.589
server endpoint for Cisco AnyConnect,
which is available as hardware appliance

00:11:55.589 --> 00:12:03.430
and also as a virtual version running on,
for example, VMware. At the beginning of

00:12:03.430 --> 00:12:08.089
our research, we tried to obtain an
official evaluation license for Cisco

00:12:08.089 --> 00:12:14.270
ASAv, while never hiding the purpose of
wanting to use it for security research.

00:12:14.270 --> 00:12:21.290
Therefore our naive approach was to just
write the Cisco licensing support. It was

00:12:21.290 --> 00:12:25.880
more or less like: Hi, we are doing
security research on the Cisco AnyConnect

00:12:25.880 --> 00:12:32.130
clients. Could you offer us free evalution
licenses for Cisco ASAv? Cisco replied:

00:12:32.130 --> 00:12:38.220
Sure. Please let me know the amount of
licenses that you need. At that point, we

00:12:38.220 --> 00:12:43.290
were a bit surprised because it just
seemed a bit too easy. But then we had

00:12:43.290 --> 00:12:50.170
three 60-day licenses added to our
account. But as soon as we tried to

00:12:50.170 --> 00:12:55.940
download the ASAv image for VirtualBox, we
got this error. Maybe some kind of error

00:12:55.940 --> 00:13:00.930
on the license was not applied correctly,
because if you have the license for

00:13:00.930 --> 00:13:06.209
products, you can of course download it,
right? Um yeah, but it seemed that our

00:13:06.209 --> 00:13:11.090
approach was a little bit naive and we
underrated the complexity of enterprise

00:13:11.090 --> 00:13:20.939
software licensing. So it was a bit
unsatisfying. But we had an idea. We asked

00:13:20.939 --> 00:13:26.120
the data center of our university for help
as university was using Cisco AnyConnect

00:13:26.120 --> 00:13:32.829
too. But we never got any response. We
still had some options, but at some point

00:13:32.829 --> 00:13:38.540
we just gave up.
G: As there is no proper documentation for

00:13:38.540 --> 00:13:44.230
AnyConnect yet, it was initially necessary
to understand the application and to

00:13:44.230 --> 00:13:49.690
filter out its central components.
Therefore, we had no choice but to reverse

00:13:49.690 --> 00:13:58.649
engineer the application. We analyzed the
application files and network traffic.

00:13:58.649 --> 00:14:03.980
In order to better understand the applica-
tion we used standard tools like Ghidra

00:14:03.980 --> 00:14:09.560
for static code analysis. The Ghidra is
able to decompile the source code of the

00:14:09.560 --> 00:14:15.899
compiled binary or library. For dynamic
application analysis we used tools like

00:14:15.899 --> 00:14:22.740
Frida, Burp and Wireshark. Frida can be
used to attach to running processes and to

00:14:22.740 --> 00:14:28.470
understand the program flow. Burp was used
as a proxy to view and modify https

00:14:28.470 --> 00:14:35.899
messages, and Wireshark is used to capture
and decrypt message traffic. Let's take a

00:14:35.899 --> 00:14:41.390
closer look at the binaries of all the
files first. AnyConnect comes with a large

00:14:41.390 --> 00:14:45.890
number of binaries. While reversing we
could identify three central parts of the

00:14:45.890 --> 00:14:52.160
application: vpnui is a binary a user
interacts with. It offers the graphical

00:14:52.160 --> 00:14:58.570
user interface, where the user can make
simple settings or initiate a VPN

00:14:58.570 --> 00:15:05.339
connection. The second binary is
vpnagentd. It runs as a daemon in the

00:15:05.339 --> 00:15:11.670
background at all times, even when no VPN
connection is open. The special thing

00:15:11.670 --> 00:15:17.680
about vpnagentd is that it runs as a root
process and always listens on a static

00:15:17.680 --> 00:15:25.130
port. Its purpose is to set up the VPN
tunnel and the network configuration of

00:15:25.130 --> 00:15:32.899
the host system. This includes setting up
routes or DNS servers. The third and last

00:15:32.899 --> 00:15:38.040
binary is the vpndownloader. As the name
hints, the purpose of the binary is to

00:15:38.040 --> 00:15:43.570
download additional files when
establishing a VPN connection. This

00:15:43.570 --> 00:15:51.020
includes VPN profiles, help files and
scripts. The binary exchanges data with

00:15:51.020 --> 00:15:59.819
each other via inter-process communication
or short IPC. The IPC takes place via TCP

00:15:59.819 --> 00:16:05.840
sockets. The binary data format for - that
Cisco has defined is used to exchange the

00:16:05.840 --> 00:16:15.670
messages on the TCP sockets. In addition
to the binaries, AnyConnect also contains

00:16:15.670 --> 00:16:20.960
numerous libraries. Many of them are ports
of existing open source libraries like

00:16:20.960 --> 00:16:29.620
OpenSSL. The most important libraries are
shown on this slide: libvpnapi.so contains

00:16:29.620 --> 00:16:35.670
interfaces and functions for the backend
logic of user interfaces. The goal of the

00:16:35.670 --> 00:16:41.089
library is that it com - that companies
can create their own VPN applications

00:16:41.089 --> 00:16:47.240
using the AnyConnect infrastructure. It is
the only library for which documentation

00:16:47.240 --> 00:16:54.420
is actually provided by Cisco.
Libvpncommoncrypt serves as a wrapper for

00:16:54.420 --> 00:17:01.430
OpenSSL and NSS libraries. NSS is similar
to OpenSSL and is used by browsers like

00:17:01.430 --> 00:17:07.860
Mozilla Firefox to enable SSL and TLS
connections. It also provides its own

00:17:07.860 --> 00:17:16.709
certificate store. Libvpncommon is another
central library used by all binaries. It

00:17:16.709 --> 00:17:23.189
provides classes and functions for the IPC
logic. It can be used to create, send or

00:17:23.189 --> 00:17:30.290
validate lPC messages. The next library,
libvpnagentutilities, contains classes and

00:17:30.290 --> 00:17:36.700
functions that handle critical operations,
such as host network settings. This

00:17:36.700 --> 00:17:45.150
library is only used by vpnagentd. Besides
the binaries and libraries there are a

00:17:45.150 --> 00:17:51.720
variety of other relevant files that we
have taken a closer look at. AnyConnect

00:17:51.720 --> 00:17:59.420
offers an AnyConnect local policy XML
file. This file regulates various security

00:17:59.420 --> 00:18:04.420
configurations. For instance, it can be
used to specify that no further files may

00:18:04.420 --> 00:18:11.740
be downloaded or that version updates may
be carried out by a VPN server. In its

00:18:11.740 --> 00:18:15.840
default configuration it is very
permissive so that almost everything is

00:18:15.840 --> 00:18:20.911
allowed. The file is not overwritten by
updates and cannot be modified by VPN

00:18:20.911 --> 00:18:30.830
servers. The VPN profile is also in XML
format: it contains further settings. The

00:18:30.830 --> 00:18:36.960
green highlighted line shows an
EnableScripting-tag with a boolean value

00:18:36.960 --> 00:18:43.820
of false. Indicating that scripts should
not be executed by the host system.

00:18:43.820 --> 00:18:50.200
Profile files are distributed by a VPN
server. And are overwritten the next time

00:18:50.200 --> 00:19:00.450
a user connects and changes them. The last
file is VPNManifest.dat which has a binary

00:19:00.450 --> 00:19:05.940
data format that contains the version
number of AnyConnect. This file is used to

00:19:05.940 --> 00:19:11.800
check the installed version of AnyConnect
before an version update. In addition to

00:19:11.800 --> 00:19:19.290
all these files, the message traffic also
plays a central role. The establishment of

00:19:19.290 --> 00:19:24.870
a VPN connection is structured in three
phases. Phase one is the authentication.

00:19:24.870 --> 00:19:33.750
The user enters the IP or domain of a VPN
server in vpnui. The target server is then

00:19:33.750 --> 00:19:41.490
sent via IPC message to vpnagentd. As a
response vpnui receives various system

00:19:41.490 --> 00:19:48.679
information back. This includes the
operating system or a whole study.

00:19:48.679 --> 00:19:53.790
Afterwards this information and the
credentials are sent to the VPN server

00:19:53.790 --> 00:20:04.160
with HTTPS. The ASA returns server
parameters in a HTTPS response. Let's take

00:20:04.160 --> 00:20:10.150
a closer look at the request and the
response. On the left side, you can see

00:20:10.150 --> 00:20:15.840
the request. It is an ordinary post
request with an XML in which the

00:20:15.840 --> 00:20:22.220
credentials are transferred. The
credentials are marked in green.

00:20:22.220 --> 00:20:28.130
On the right side we see the response. The
response contains the session token, which

00:20:28.130 --> 00:20:33.420
is also marked in green. In addition, the
response contains the URLs to all

00:20:33.420 --> 00:20:40.210
downloadable files and the hashes. The
orange marked string is one of the

00:20:40.210 --> 00:20:47.580
downloadable files. The download phase is
the second phase of the VPN connection set

00:20:47.580 --> 00:20:55.620
up. First vpnui executes the vpndownloader
binary. Then the server parameters from

00:20:55.620 --> 00:21:03.144
the previous HTTPS response are
transferred to the vpndownloader via IPC.

00:21:03.144 --> 00:21:09.620
The URLs are extracted from the IPC
message and when the files are downloaded

00:21:09.620 --> 00:21:18.310
to a temporary directory via HTTPS. The
downloader process informs the vpnagentd

00:21:18.310 --> 00:21:24.320
via IPC to move the files to the
application directory. In the third and

00:21:24.320 --> 00:21:31.010
final phase of VPN connection set up,
vpnui sends an IPC message to vpnagentd

00:21:31.010 --> 00:21:36.850
with the request to establish a VPN
tunnel. Subsequently, the exchange of

00:21:36.850 --> 00:21:44.145
tunnel parameters takes place via HTTPS.
After the parameters have been set by

00:21:44.145 --> 00:21:50.640
vpnagentd the VPN session continues. Let's
take a closer look at the tunnel

00:21:50.640 --> 00:21:57.970
parameters. On the left side, we can see
the request. In the first line you can

00:21:57.970 --> 00:22:03.990
observe the HTTP connect method. Usually
this method is used to proxies to forward

00:22:03.990 --> 00:22:10.080
the request to the target server. Within
the request, the session token is

00:22:10.080 --> 00:22:15.530
specified in the cookie header. This is
the same session token we received in the

00:22:15.530 --> 00:22:22.330
authentication phase. The different tunnel
parameters transmitted in separate HTTP

00:22:22.330 --> 00:22:30.160
headers. The part marked in red represents
the local IP address of the host. On the

00:22:30.160 --> 00:22:35.660
right, you can see a response to the
request. For example, the X-CSTP-Address

00:22:35.660 --> 00:22:43.470
header contains the IP address that the
host should apply on its tunnel interface.

00:22:43.470 --> 00:22:50.060
In the part marked in red we now also see
the DNS server for the VPN

00:22:50.060 --> 00:22:56.090
connection. In addition, the address
ranges that should be routed via the VPN

00:22:56.090 --> 00:23:04.402
server as specified in the X-CSTP-Split-
Include header. Now that we have a general

00:23:04.402 --> 00:23:09.569
understanding of the application, let's
move on to the vulnerability research. We

00:23:09.569 --> 00:23:15.919
have performed an design analysis for
AnyConnect in which we looked at the IPC

00:23:15.919 --> 00:23:21.729
messages in more detail. We need to define
certain security assumptions and an

00:23:21.729 --> 00:23:26.400
attacker model before we search for
vulnerabilities. This slide shows several

00:23:26.400 --> 00:23:33.020
of our assumptions. Cryptographic
algorithms within the application are

00:23:33.020 --> 00:23:39.460
considered secure and cannot be broken in
exponential time. An attacker cannot read

00:23:39.460 --> 00:23:44.679
or modify messages regardless of their
position, and we assume that the VPN

00:23:44.679 --> 00:23:51.170
server does not pursue any malicious
intent and only sends valid messages that

00:23:51.170 --> 00:23:56.780
are protocol compliant. We assume a local
attacker who is already able to execute

00:23:56.780 --> 00:24:01.460
commands on the system and the attackers
goal is to compromise the confidentiality,

00:24:01.460 --> 00:24:08.340
integrity and availability of the system
or application. Privilege escalation

00:24:08.340 --> 00:24:13.830
vulnerabilities are also covered since
they allow an attacker to compromise these

00:24:13.830 --> 00:24:20.550
three security objectives. Cisco decided
to include an auto update feature in the

00:24:20.550 --> 00:24:27.929
application. AnyConnect is able to receive
AnyConnect updates through a VPN server

00:24:27.929 --> 00:24:32.470
without any user interaction. In its
default configuration AnyConnect can be

00:24:32.470 --> 00:24:38.740
updated by a VPN server that offers a
newer version. From a security

00:24:38.740 --> 00:24:44.950
researcher's perspective auto update
sounds promising, right? So let's take a

00:24:44.950 --> 00:24:49.510
closer look at the auto update feature.
First, the vpndownloader downloads an

00:24:49.510 --> 00:24:57.010
executable installer and the shell script
called vpndownloader.sh. Then

00:24:57.010 --> 00:25:03.630
vpndownloader.sh is executed. The Shell
script contains an archive and unpacks

00:25:03.630 --> 00:25:09.380
itself to extract a new version of the
vpndownloader. An IPC message is then sent

00:25:09.380 --> 00:25:15.740
to the vpnagentd asking it to start the
installer. The vpnagentd does not start

00:25:15.740 --> 00:25:21.429
the installer directly. Instead the
vpnagentd calls the vpndownloader with

00:25:21.429 --> 00:25:28.059
root privileges, which in turn calls the
installer. Before executing the installer

00:25:28.059 --> 00:25:35.100
vpndownloader verifies and validates it.
We got an idea: Is it possible to install

00:25:35.100 --> 00:25:40.909
an outdated version through forged IPC
messages? As shown in the picture the

00:25:40.909 --> 00:25:47.780
attacker needs an old signed installer and
sends the IPC message to vpnagentd asking

00:25:47.780 --> 00:25:53.679
to execute the old installer. The
vpnagentd calls the vpndownloader as

00:25:53.679 --> 00:25:58.710
usual, which in turn calls the attacker's
installer. There is no check whether the

00:25:58.710 --> 00:26:05.289
installer is more recent than the
installed version. This makes the version

00:26:05.289 --> 00:26:10.720
downgrade therefore possible. The
advantage of downgrading to an outdated

00:26:10.720 --> 00:26:15.650
version is that an attacker could force
the installation of a version which

00:26:15.650 --> 00:26:21.179
suffers from security vulnerabilities and
the attacker could then exploit these

00:26:21.179 --> 00:26:28.520
vulnerabilities. We reported the
vulnerability to Cisco's product incident

00:26:28.520 --> 00:26:34.020
response team and it was fixed at the end
of September. The vulnerability only

00:26:34.020 --> 00:26:42.390
received a CVSS score of 3.1 and was
therefore rated with a low severity. The

00:26:42.390 --> 00:26:47.959
vulnerability was only exploitable in the
Linux version. Windows and Mac versions

00:26:47.959 --> 00:26:54.600
were already secured against such an
attack. Another functionality we had - we

00:26:54.600 --> 00:26:59.720
have looked into is the deployment and
execution of scripts. They call it "Bring

00:26:59.720 --> 00:27:05.730
your own script". This functionality is
intended to deploy very helpful scripts to

00:27:05.730 --> 00:27:11.350
staff computers. In order for a script to
be executed, it must meet two criterias.

00:27:11.350 --> 00:27:16.880
First, it must be located in the script
folder and begin with OnConnect or

00:27:16.880 --> 00:27:24.150
OnDisconnect as a file name. Second, the
EnableScripting tag in profile which is

00:27:24.150 --> 00:27:31.760
sent by the server must be set to true.
Depending on the file name, scripts are

00:27:31.760 --> 00:27:37.002
triggered after VPN connection is
established and terminated. As VPN server

00:27:37.002 --> 00:27:42.980
can distribute profiles in which the
execution of scripts is enabled and also

00:27:42.980 --> 00:27:48.289
distributes the scripts: these two in
combination allow VPN server to gain

00:27:48.289 --> 00:27:54.410
remote code execution on the connecting
clients. This functionality poses a major

00:27:54.410 --> 00:27:59.299
problem because humans often need to trust
the university's VPN servers and have no

00:27:59.299 --> 00:28:05.539
other choice. But let's take a closer look
at the distribution of the scripts. Here

00:28:05.539 --> 00:28:11.850
we see the classic procedure of a script
distribution. In the download phase,

00:28:11.850 --> 00:28:19.171
vpndownloader downloads an OnConnect or an
OnDisconnect script. Then vpndownloader

00:28:19.171 --> 00:28:25.419
asks with IPC message to move the
downloaded script to the script folder.

00:28:25.419 --> 00:28:32.570
The vpnagentd process calls the
vpndownloader, which then moves the file.

00:28:32.570 --> 00:28:36.670
We systematically examined the IPC
messages and found a vertical privilege

00:28:36.670 --> 00:28:43.100
escalation. An attacker is able to send
the same message to the vpnagentd process.

00:28:43.100 --> 00:28:48.350
Any of the attacker's scripts can be moved
into the script directory. If there is

00:28:48.350 --> 00:28:52.970
already a script in the script folder, it
is simply overwritten. If the attacker

00:28:52.970 --> 00:28:58.620
moves On, an OnDisconnect script while
the user is already - has a VPN connection

00:28:58.620 --> 00:29:04.610
open, the script is executed with user
privileges. When the VPN connection is

00:29:04.610 --> 00:29:13.220
closed, first unprivileged user can obtain
code execution context of another user.

00:29:13.220 --> 00:29:18.450
What bothered us about our attack was that
it is - was tied to conditions. One of the

00:29:18.450 --> 00:29:24.040
conditions was that the EnableScripting
tag must have the boolean value "True". We

00:29:24.040 --> 00:29:29.020
considered other attack scenarios and came
up with the idea of distributing a profile

00:29:29.020 --> 00:29:34.620
ourselves. So we check for the tag again,
but create not only a script, but also a

00:29:34.620 --> 00:29:41.210
VPN profile that allows scripting. The
attack works as follows: while a local

00:29:41.210 --> 00:29:45.580
user has a VPN session active, another
user on the system creates a malicious

00:29:45.580 --> 00:29:50.539
script and a new profile. The new profile
contains the EnableScripting tag set to

00:29:50.539 --> 00:29:57.059
"True". The attacker then sends an IPC
message to the vpnagentd requesting to

00:29:57.059 --> 00:30:03.029
copy the script to the script directory.
The vpndownloader is then started with

00:30:03.029 --> 00:30:10.990
root permissions to perform the copy
operation. Also, the attacker can send an

00:30:10.990 --> 00:30:17.039
additional IPC message to vpnagentd
requesting to overwrite the

00:30:17.039 --> 00:30:24.809
existing profile with a malicious profile.
Although the profile is overwritten the

00:30:24.809 --> 00:30:29.109
settings of a new profile are not applied
yet, because the old profile is still

00:30:29.109 --> 00:30:34.950
active. However, we were able to determine
that the new profile is loaded when

00:30:34.950 --> 00:30:41.503
there's a reconnect on the VPN session.
Reconnects are actually quite common in

00:30:41.503 --> 00:30:46.329
the AnyConnect. If reconnect happens the
new profile is loaded and applied. In our

00:30:46.329 --> 00:30:51.230
case, it enables the scripting feature.
After teardown of a VPN connection the

00:30:51.230 --> 00:30:56.490
malicious OnDisconnect script of the
attacker is executed with the privileges

00:30:56.490 --> 00:31:03.010
of the user running the VPN client. Both
problems were reported to Cisco, but could

00:31:03.010 --> 00:31:07.580
not be fixed by the disclosure date.
Although we extended the disclosure

00:31:07.580 --> 00:31:12.020
deadline. As of today the vulnerability is
still present with the default

00:31:12.020 --> 00:31:18.029
configuration of AnyConnect. Cisco
published this vulnerability with a CVSS

00:31:18.029 --> 00:31:25.910
of 7-1, 7.1, which is considered as a high
severity. Because it was published on the

00:31:25.910 --> 00:31:32.340
4th of November 2020 without a fix, the
vulnerability got major attention in many

00:31:32.340 --> 00:31:42.410
news sites. Various sites reported the
vulnerability. The quality of reports

00:31:42.410 --> 00:31:47.410
varied. Some of the articles contained
incorrect information, for example, it was

00:31:47.410 --> 00:31:52.820
stated that an exploit was already in
circulation. It is not accurate since we

00:31:52.820 --> 00:31:57.990
are the only ones who have a working
exploit and have not published it yet. We

00:31:57.990 --> 00:32:03.190
could not find any other exploit on the
Internet either. I think that the way of

00:32:03.190 --> 00:32:09.539
reporting - this way of reporting has to
be reconsidered because it has caused a so

00:32:09.539 --> 00:32:15.450
wrong assessment of vulnerability. We were
even contacted by some incident response

00:32:15.450 --> 00:32:21.370
teams that were worried about their
infrastructure. All vulnerabilities found

00:32:21.370 --> 00:32:25.130
and reported are listed in the table
below. The three vulnerabilities were

00:32:25.130 --> 00:32:30.350
found by design analysis. Only one of the
vulnerabilities is fixed, according to

00:32:30.350 --> 00:32:37.980
Cisco. Especially the Bring Your Own
Script vulnerabilities have already been

00:32:37.980 --> 00:32:42.760
published, although no fix is available
for them, a workaround has been declared

00:32:42.760 --> 00:32:49.860
to fix the vulnerabilities. By modifying
the local policy file the download phase

00:32:49.860 --> 00:32:54.450
can be skipped completely. Since the
latest update it's also possible to

00:32:54.450 --> 00:32:59.679
prohibit the download and deployment of
scripts on a modular basis.

00:32:59.679 --> 00:33:05.309
M: And what about mobile platforms? Do our
discovered vulnerabilities also apply

00:33:05.309 --> 00:33:11.720
here? Let's make it quick. No. Mobile
platforms are lacking many features

00:33:11.720 --> 00:33:15.740
compared to the Linux, Windows and macOS
versions. You're, of course, able to

00:33:15.740 --> 00:33:20.730
establish TLS and IPsec connections, just
like with all the other clients. But

00:33:20.730 --> 00:33:24.649
because features like the deployment of
custom scripts or auto update is missing,

00:33:24.649 --> 00:33:30.010
there's no way of using these exploits on
mobile platforms. We are currently having

00:33:30.010 --> 00:33:35.000
a look into the iOS implementation of
AnyConnect and therefore want to give you

00:33:35.000 --> 00:33:41.430
a quick and high level overview into the
architecture. As we are dealing with Apple

00:33:41.430 --> 00:33:45.570
here, serious stuff like the
implementation of the VPN is a bit

00:33:45.570 --> 00:33:51.929
different compared to, for example, the
Linux client. If you want to mess with

00:33:51.929 --> 00:33:56.399
notifications, add sharing buttons or
create a widget on the homescreen, you

00:33:56.399 --> 00:34:01.740
have to use an app extension. Equally for
VPN functionality, you have to use the

00:34:01.740 --> 00:34:08.429
network extension framework. The network
extensions contain providers and features

00:34:08.429 --> 00:34:14.099
for all kind of network related operations
like for content filtering, DNS, Wi-Fi and

00:34:14.099 --> 00:34:18.940
more. If you want to build your own VPN
app, you have to choose between the

00:34:18.940 --> 00:34:25.839
Personal VPN, the Packet Tunnel Provider
and the App Proxy Provider. In our case

00:34:25.839 --> 00:34:30.079
the AnyConnect on iOS implements the
Packet Tunnel Provider as they are using

00:34:30.079 --> 00:34:38.279
their own packet oriented protocol. Here
you can see the contents of the AnyConnect

00:34:38.279 --> 00:34:43.469
app package, which is basically a zip file
containing all the executables and other

00:34:43.469 --> 00:34:49.819
assets like images, etc.. The main
executable is just called AnyConnect. The

00:34:49.819 --> 00:34:56.209
network extension is implemented in the
ACExtension binary. Beside these, there

00:34:56.209 --> 00:35:01.799
are also several other app extension
implementations for the iOS sharing and

00:35:01.799 --> 00:35:08.910
Siri functionality. So what happens if you
pressed the connect slider? After you hit

00:35:08.910 --> 00:35:13.329
the slider, the network extension is
started and negotiation of the VPN session

00:35:13.329 --> 00:35:19.059
begins. After a section of network
information like IP addresses, subnet

00:35:19.059 --> 00:35:23.130
mask, routes, DNS, MTU and more they are
passed to the iOS system to complete the

00:35:23.130 --> 00:35:29.390
negotiation. In the end, you have a new
and hopefully functional tunnel interface

00:35:29.390 --> 00:35:36.930
called utun. So new traffic from apps pass
through the network stack until it arrives

00:35:36.930 --> 00:35:41.619
at the tunnel interface. It can then be
handled by the network extensions' Packet

00:35:41.619 --> 00:35:48.269
Tunnel Provider. Every time a packet
arrives on a tunnel interface, it is read

00:35:48.269 --> 00:35:54.191
by the network extension and encapsulated
with the tunneling protocol. Every time a

00:35:54.191 --> 00:35:59.020
packet arrives on the tunnel interface, it
is read by the network extension and

00:35:59.020 --> 00:36:04.660
encapsulated with the tunneling protocol.
Upon arrival on the VPN server, the packet

00:36:04.660 --> 00:36:10.150
is decapsulated and sent to its final
destination. Similar the replies then

00:36:10.150 --> 00:36:14.690
encapsulate sent to the client, which then
decapsulates the packet and injects it

00:36:14.690 --> 00:36:20.499
back to the network stack. So that's
should be it for the iOS clients, just to

00:36:20.499 --> 00:36:23.829
give you a quick overview and highlight
some key differences between the

00:36:23.829 --> 00:36:30.930
architectures. We are still investigating
both Linux and iOS platforms, but until

00:36:30.930 --> 00:36:35.700
now, we can summarize our findings as
follows: AnyConnect in general is a huge

00:36:35.700 --> 00:36:42.530
application with lots of code and also
lots of unused library related code. We

00:36:42.530 --> 00:36:48.510
discovered three vulnerabilities through
design analysis. Vpnagentd runs with root

00:36:48.510 --> 00:36:53.529
permissions and receives commands or
operations from unprivileged processes via

00:36:53.529 --> 00:36:59.549
unauthenticated IPC messages, which is
generally a bit risky. Not all security

00:36:59.549 --> 00:37:03.999
mechanisms and patches are actually
included on all platforms. For example,

00:37:03.999 --> 00:37:08.619
the downgrade was only possible on Linux
and already patched on Windows and macOS

00:37:08.619 --> 00:37:14.369
according to Cisco. The downgrade
vulnerability is not possible on mobile,

00:37:14.369 --> 00:37:19.430
as auto update feature is limited to
Linux, Windows and macOS. Similar, the

00:37:19.430 --> 00:37:24.119
Bring Your Own Script does also not apply
in mobile, as deployment of OnConnect and

00:37:24.119 --> 00:37:29.180
OnDisconnect script is also limited to
Linux, Windows and macOS. Regarding the

00:37:29.180 --> 00:37:34.009
local policy file on Linux, our idea would
be to make it as restrictive as possible

00:37:34.009 --> 00:37:39.219
and require some kind of opt-in for
scripting functionality. As this would

00:37:39.219 --> 00:37:44.140
prevent many attacks but of course, it
would also impact the usability a bit.

00:37:44.140 --> 00:37:48.779
Despite the app being available since many
years, we show that there are still many

00:37:48.779 --> 00:37:54.279
bugs to find. The introduction of bug
bounties would be a great option to

00:37:54.279 --> 00:38:00.859
motivate more security researchers to
check the application for vulnerabilities.

00:38:00.859 --> 00:38:06.799
The use of VPN promises security and
privacy for users, however closed source

00:38:06.799 --> 00:38:11.049
software opens new attack vectors on a
system as our research on AnyConnect

00:38:11.049 --> 00:38:16.559
shows. We hope that more research will be
done on clients in the future and that our

00:38:16.559 --> 00:38:24.460
work will pave the way for this. So that
was it. Thank you very much for your

00:38:24.460 --> 00:38:29.610
attention and if you have any questions,
feel free to ask.

00:38:30.700 --> 00:38:35.599
H: Well, welcome back. So that was the
pre-recording of the super interesting

00:38:35.599 --> 00:38:41.239
talk about Very Pwnable Networks. I'm sure
you've seen how pwnable they really are

00:38:41.239 --> 00:38:48.630
and luckily, we now have Jiska and Gerbert
and Matthias with us today through the

00:38:48.630 --> 00:38:56.499
magic of the Internet. And if you haven't
written out your question yet, please do

00:38:56.499 --> 00:39:05.869
so now so we can still answer them. Either
by going to the IRC channel rc3-cwtv on

00:39:05.869 --> 00:39:12.219
the hackened network or just posting a
tweet or a toot with your favorite social

00:39:12.219 --> 00:39:19.490
media network of choice containing the
hashtag #rc3cwtv this time without any

00:39:19.490 --> 00:39:27.629
dash, very important. So our Signal Angel
has collected some questions for us that I

00:39:27.629 --> 00:39:33.280
am now going to be torturing the three
people here with. So let's see what you

00:39:33.280 --> 00:39:41.799
will say to those. Oh, but I think pretty,
pretty tame, huh? So first question: is

00:39:41.799 --> 00:39:45.839
there any page or wiki where this
information can be found?

00:39:45.839 --> 00:39:53.150
G: At the moment, it is not published yet.
I think we will publish - publish it in

00:39:53.150 --> 00:39:58.952
near future on the GitHub or some similar
platform.

00:39:58.952 --> 00:40:02.940
H: Is there any way that people can find
this link then when you eventually will

00:40:02.940 --> 00:40:07.630
publish it in the future?
G: I think Jiska can say something to this

00:40:07.630 --> 00:40:10.579
J: Yeah so SEEMOO has a GitHub page and

00:40:10.579 --> 00:40:16.249
also a Twitter account, so it will be
published. But I mean, there's still a few

00:40:16.249 --> 00:40:21.680
things that we didn't like - that are not
public yet. So yeah, and then we would

00:40:21.680 --> 00:40:27.420
just make one release not like this CVE
and that CVE, but like all at once.

00:40:27.420 --> 00:40:31.519
H: Yeah. Make - makes more of an impact
this way and also better, better

00:40:31.519 --> 00:40:38.160
disclosure. I like that. And the next
question is: will this VPN event only be

00:40:38.160 --> 00:40:46.420
about Cisco? So yes, you've only looked at
Cisco, right? In this case. Um, maybe you

00:40:46.420 --> 00:40:50.729
can tell us something if maybe you have
looked at other VPN vendors as to

00:40:50.729 --> 00:40:55.589
something that other VPN vendors might
have an issue with as well? Maybe.

00:40:55.589 --> 00:41:01.670
M: Yeah, we've done this research as part
of a master's thesis, and therefore it's

00:41:01.670 --> 00:41:10.059
only about Cisco AnyConnect and yeah, we
did not have the time to - or yeah. Yeah.

00:41:10.059 --> 00:41:14.408
To look at other VPN services, just for
the AnyConnect.

00:41:14.408 --> 00:41:19.630
H: Yeah, the typical Master's view writing
it hyped up on coffee for the last few

00:41:19.630 --> 00:41:25.190
weeks before the deadline. Yeah, I can
imagine that you focused on Cisco there.

00:41:25.190 --> 00:41:30.630
Uum, another very good question: Are these
vulnerabilities also present in other - in

00:41:30.630 --> 00:41:35.039
other AnyConnect-like clients like the
ones integrated into NetworkManager in

00:41:35.039 --> 00:41:40.309
Linux? I think they're talking especially
about OpenConnect. Yeah, that's just

00:41:40.309 --> 00:41:45.749
coming in. Umm, we talked about this
before a little bit so you probably have

00:41:45.749 --> 00:41:50.210
something to say about that.
G: As far as we know there's - in

00:41:50.210 --> 00:41:56.999
OpenConnect there is no scripting -
scripting feature enabled or integrated.

00:41:56.999 --> 00:42:03.630
So we would say this kind of attacks are
not yet possible, but uh -

00:42:03.630 --> 00:42:10.559
M: That would be possible if someone is
able to check this and, yeah, have a look

00:42:10.559 --> 00:42:15.680
into OpenConnect too, yeah.
H: Hmm, yeah, not yet known to be

00:42:15.680 --> 00:42:24.059
possible. Let's - let's say it like that.
You never know. Any other questions from

00:42:24.059 --> 00:42:31.439
chat, from Twitter or Mastodon? Now's the
time. Give out your questions. Otherwise,

00:42:31.439 --> 00:42:40.480
this would have been a very short Q&amp;A. So
if you go to the rc3-cwtv channel on the

00:42:40.480 --> 00:42:49.319
hackened IRC network or post a tweet or a
toot with the hashtag #rc3cwtv this time

00:42:49.319 --> 00:42:56.150
without any dash. Umm, do it now, and
hopefully I will still catch this

00:42:56.150 --> 00:43:00.890
through the magic of the Signal Angel that
is collecting all this information for me.

00:43:00.890 --> 00:43:05.549
And yeah, maybe anything that you want to
add or any other new topics that you're

00:43:05.549 --> 00:43:09.339
working on, something that might be
upcoming. Maybe we can get a sneak

00:43:09.339 --> 00:43:13.589
preview. I'm sure you're still continuing
the research there - and 

00:43:13.589 --> 00:43:15.799
J: Sorry I needed to unmute myself. Not

00:43:15.799 --> 00:43:20.249
spoilering yet but I mean, the issue like
just looking into one VPN client it's

00:43:20.249 --> 00:43:25.838
also, if it is proprietary, then just
reversing is a lot, a lot, a lot of work.

00:43:25.838 --> 00:43:32.630
I mean, I can tell you a story about like,
looking into binaries for months, and so

00:43:32.630 --> 00:43:37.819
it doesn't really scale to look into like
10 different clients, at least if you want

00:43:37.819 --> 00:43:44.479
to have meaningful findings.
H: Yeah, but like you don't have any any

00:43:44.479 --> 00:43:51.349
other plans to, you know, look at any
other clients that get any requests or any

00:43:51.349 --> 00:43:56.609
triggers that would point you there. Maybe
having a new phone and a new client and

00:43:56.609 --> 00:44:02.309
noticing new strange things? No? - Okay.
G: Not yet.

00:44:02.309 --> 00:44:06.010
J: Yeah.
G: But, but yes, Matthias is still working

00:44:06.010 --> 00:44:10.930
on it. I think he will find something in
the future. M: hopefully.

00:44:10.930 --> 00:44:21.039
H: Yeah. Yeah. I guess that's pretty much
all the last questions, except one: There

00:44:21.039 --> 00:44:26.339
are two shadows behind you Jiska, is that
the shadow cabinet?

00:44:26.339 --> 00:44:29.629
J: No, no, no. I just have multiple lamps
here. So -

00:44:29.629 --> 00:44:31.476
H: Yeah, yeah, it's funny everyone &lt;??&gt;

00:44:31.476 --> 00:44:34.509
J: At least it's only showing my shadow
duplicate. Not - not me.

00:44:34.509 --> 00:44:39.739
H: Yeah. But we're quite lucky that at
least in this talk, the connection seems

00:44:39.739 --> 00:44:46.089
to be working fine. We've been having some
issues here. Yeah, but that's great. If

00:44:46.089 --> 00:44:51.280
you have any other questions, I think
we'll wrap it up here not to keep you

00:44:51.280 --> 00:44:57.420
around much longer. I'm sure you're eager
to jump around the rc3 world, and if you

00:44:57.420 --> 00:45:03.469
have anything else, maybe you can join us
in the IRC later. If there are any other

00:45:03.469 --> 00:45:08.859
questions, maybe they will look there for
a short while or I will forward those

00:45:08.859 --> 00:45:12.239
questions. Right then.
J: Thank you.

00:45:12.239 --> 00:45:16.569
H: I thank you very much for the super
interesting talk. I learned something new

00:45:16.569 --> 00:45:20.809
about the VPN client that I came into
contact with during my work time as well.

00:45:20.809 --> 00:45:28.169
So interesting for me too. And yeah, let's
keep it at that.

00:45:28.169 --> 00:45:35.749
<i>postroll music</i>

00:45:35.749 --> 00:45:52.559
Subtitles created by c3subtitles.de
in the year 2022. Join, and help us!

00:45:52.559 --> 00:45:59.000
[Translated by {Iikka}{Yli-Kuivila}
(ITKST56 course assignment at JYU.FI)]