[Translated by {Iikka}{Yli-Kuivila}
(ITKST56 course assignment at JYU.FI)]

<i>33C3 preroll music</i>

Herald: Welcome back to the festival
stage, still day two according to my

clock, even though I have lost all sense
of time by now, I don't know. It's like a

kind of rush year with so many great
talks, and we'll have the next super

awesome talk held by Jiska, Gerbert and
Matthias. And those three lovely people

will be showing us something about VPNs.
So-called very pwnable networks and why

your VPN might not be as secure as you
think or have been led to believe. And

this is not only important for the people
that think like, haha, I'm behind seven

proxies. You can't catch me. But also,
maybe if your employer says, please use

this VPN client and there might be some
surprises waiting for you. And this is

again, a pre-recording, and afterwards I
can already see them here in our tools,

but afterwards we will do a Q&amp;A session.
So if you have any questions, put them

into the IRC or on Twitter or Mastodon
with the hashtag #rc3cwtv. And our lovely

Signal Angel will collect them and we'll
see each other after the pre-recording.

Jiska: Everyone and welcome to the talk

Very Pwnable Network which is by Gerbert,
Matthias and me. So how did all start?

Well, I got a little bit paranoid last
year and I just thought it might be a good

idea to encrypt a lot because Wi-Fi, LTE,
TLS it might be intercepted, might be

decrypted. So we should encrypt like
everyone is watching and so I should use a

VPN on top. And then the next trust
assumption was that I connect to my

university's network every day, so I
should trust this one anyway. And if I

trust this network, then I could also use
this network and their professional VPN

service. I hear you laughing, I hear
laughing but so this was my idea because

then there is no additional thing that I
trust during my network activity. And

well, they had this nice AnyConnect line
that just works on all operating systems.

So it also sounds like a great product
name for a secure product like AnyConnect.

Yeah. And then I started using this on my
mobile devices, right? And then suddenly I

got crash logs and it looked like this. So
I mean, if you're paranoid, you obviously

look into your crash logs every two days
and one of these crash logs was this one.

It didn't really look nice the address
looks a bit strange, and you also have

some trace of the crashed thread. And if
you log this into IDA and do a little bit

of reverse engineering, you can also add
some function names in the AnyConnect

extension, the AC extension and the crash
is somewhere when it applies VPN config

somewhere in the - in the tunnel buffers.
I don't know. So - and then also, the

address looks strange because the address
is IP version four backwards and then a

few days later I got another crash and
this crash read like 68k New Line. And so

it really looked like some configuration
strings that were crashing at certain

addresses, so it really didn't look good.
But I also didn't have that much time. So

I just wrote Cisco and said, like, so do
you mean to serious like, is your client

really crashing that often? Because every
time I do my laundry, I have bad Internet

connectivity, so my any - my AnyConnect
client starts to crash at weird addresses.

And while this is like an issue for code
execution, the other issue is that if you

just jam a few packets over the air, then
an attacker might be able to disconnect

the victim from a VPN. So that is also an
issue. So because the AnyConnect client is

not properly included in the operating
system iOS, and that means that you would

just reconnect and send your messages in
plaintext over the network and the user

does not get any notification. It's just a
VPN symbol that has gone and all traffic

is sent in plaintext. And I wanted to
analyze this a little bit further and

there is a debugging option in the
AnyConnect client. But since it's in the

client that crashes, the logs are just
gone. If you have a crash and even worse

also the operating system crash logs in
iOS are missing if you have the debugging

option enabled. And well they answered:
"We cannot reproduce this". I mean,

obviously they didn't help me with my
laundry or anything so they could not

reproduce. And even worse, they ignored
the ticket for a long time until we said

we are going to present this at this
year's CCC congress. And then 10 days

before the talk they claimed that they had
fixed two out of the three crashes and

were asking if we could reproduce the
crashes or not. But just a day before they

said like they were not sure and so on. So
it was really a weird ticket there and I

have no idea if things are fixed or not,
because to reproduce, I obviously need

like tinfoil. I need like a couple of
smart phones with the AnyConnect client

installed, and then I need to walk around
and hope that the Internet connection

breaks and that it breaks in a way that
produces a crash. So this is just way too

random. I also told Apple and Apple just
said, Well, the issue is that the client

crashes so it's not really their
department, even though it's the network

extension that crashes. So it's not their
task here to notify the user. It's just

the VPN that is gone. And then you send
data in plaintext and this is all right.

This is the expected behavior. So I got a
bit annoyed and stopped using VPNs, but I

also had the idea to find students who
might look into this. And well, you know

what happens when you find very motivated
students, they find vulnerabilities. And

this is what this talk is going to be
about.

Gerbert: So we had a look at the Cisco
AnyConnect client for Linux and found some

interesting things. Shortly after
publishing our findings, several news

articles popped up. But what happened
between the crashes of Jiska and these

articles? VPN is interesting because it is
such an old research topic. However, the

importance of the technology was later
increased by the corona pandemic. Many

companies had to relocate to home offices
to meet the safety measures. VPN allows

users from outside to access internal
resources of the company or university. To

connect to a VPN server, additional client
software is usually required. Besides open

source products, such as openVPN, a lot
of closed source software is offered on

the market. Especially in the enterprise
sector. The users are forced to trust this

software, install a black box in their
system in order to connect to a network.

AnyConnect secure mobility client from
Cisco is an enterprise software solution.

AnyConnect can be classified as a remote
access client that allows end-users to

connect to a network that supports SSL VPN
and also IPsec. When using SSL VPN the

authentication and the establishment of a
VPN tunnel is carried out via an SSL or

TLS tunnel. The software acts as a fat
client that communicates with the VPN

server via HTTPS. As already mentioned the
source code for AnyConnect is not publicly

available. The application is distributed
with compiled binaries and libraries.

Although the application is documented, it
does not cover internal functionality.

Even the vulnerability disclosures, which
are published in public advisories, do not

go into much technical detail. Therefore
there is only limited knowledge about the

application and its internal behavior. We
have set ourselves the goal to examine

AnyConnect for Linux and iOS in a recent
version. The main functionality of

AnyConnect is the establishment of VPN
connections, but this is only the tip of

the iceberg. AnyConnect also connects
numerous other features, to name a few:

The distribution and execution of scripts
on host systems, automatically updating

the software without asking the user for
permission. Another feature is host scan:

it does not integrate into AnyConnect, but
it is considered as a standalone software.

It works together with the AnyConnect
infrastructure and makes it possible to

read out extensive system information of
the host and transmit them to VPN server.

The related work of AnyConnect is based on
Cisco's public advisories and blog entries

from certain security researchers.
Therefore, we decided to list and

categorize all vulnerabilities since 2011.
On this diagram, we see a list of

vulnerabilities per year, ordered by
severity. Most of the time reported

vulnerabilities are classified as medium,
but even critical vulnerabilities were

disclosed in 2011 and 2012. The increased
numbers in 2015 and 2016 caused numerous

vulnerabilities of libraries such as
OpenSSL. The vulnerabilities were then

divided into categories and illustrated in
the diagram. Cryptographic vulnerabilities

are the most common as AnyConnect uses
OpenSSL and vulnerabilities in OpenSSL are

also vulnerabilities in AnyConnect.
However, excluding the third-party

vulnerabilities, the category of most
vulnerabilities affecting AnyConnect would

be privilege escalations. Closely followed
by denial of service attacks, which are

often directed against the running
application in order to disrupt the VPN

connection. Overflow vulnerabilities or
version downgrades

These results gave us a little insight
about the flaws of the past.

Matthias: So before we will pass over to
the reversing parts, we want to give you a

quick experience report regarding Cisco's
licensing support. Cisco ASA is a typical

server endpoint for Cisco AnyConnect,
which is available as hardware appliance

and also as a virtual version running on,
for example, VMware. At the beginning of

our research, we tried to obtain an
official evaluation license for Cisco

ASAv, while never hiding the purpose of
wanting to use it for security research.

Therefore our naive approach was to just
write the Cisco licensing support. It was

more or less like: Hi, we are doing
security research on the Cisco AnyConnect

clients. Could you offer us free evalution
licenses for Cisco ASAv? Cisco replied:

Sure. Please let me know the amount of
licenses that you need. At that point, we

were a bit surprised because it just
seemed a bit too easy. But then we had

three 60-day licenses added to our
account. But as soon as we tried to

download the ASAv image for VirtualBox, we
got this error. Maybe some kind of error

on the license was not applied correctly,
because if you have the license for

products, you can of course download it,
right? Um yeah, but it seemed that our

approach was a little bit naive and we
underrated the complexity of enterprise

software licensing. So it was a bit
unsatisfying. But we had an idea. We asked

the data center of our university for help
as university was using Cisco AnyConnect

too. But we never got any response. We
still had some options, but at some point

we just gave up.
G: As there is no proper documentation for

AnyConnect yet, it was initially necessary
to understand the application and to

filter out its central components.
Therefore, we had no choice but to reverse

engineer the application. We analyzed the
application files and network traffic.

In order to better understand the applica-
tion we used standard tools like Ghidra

for static code analysis. The Ghidra is
able to decompile the source code of the

compiled binary or library. For dynamic
application analysis we used tools like

Frida, Burp and Wireshark. Frida can be
used to attach to running processes and to

understand the program flow. Burp was used
as a proxy to view and modify https

messages, and Wireshark is used to capture
and decrypt message traffic. Let's take a

closer look at the binaries of all the
files first. AnyConnect comes with a large

number of binaries. While reversing we
could identify three central parts of the

application: vpnui is a binary a user
interacts with. It offers the graphical

user interface, where the user can make
simple settings or initiate a VPN

connection. The second binary is
vpnagentd. It runs as a daemon in the

background at all times, even when no VPN
connection is open. The special thing

about vpnagentd is that it runs as a root
process and always listens on a static

port. Its purpose is to set up the VPN
tunnel and the network configuration of

the host system. This includes setting up
routes or DNS servers. The third and last

binary is the vpndownloader. As the name
hints, the purpose of the binary is to

download additional files when
establishing a VPN connection. This

includes VPN profiles, help files and
scripts. The binary exchanges data with

each other via inter-process communication
or short IPC. The IPC takes place via TCP

sockets. The binary data format for - that
Cisco has defined is used to exchange the

messages on the TCP sockets. In addition
to the binaries, AnyConnect also contains

numerous libraries. Many of them are ports
of existing open source libraries like

OpenSSL. The most important libraries are
shown on this slide: libvpnapi.so contains

interfaces and functions for the backend
logic of user interfaces. The goal of the

library is that it com - that companies
can create their own VPN applications

using the AnyConnect infrastructure. It is
the only library for which documentation

is actually provided by Cisco.
Libvpncommoncrypt serves as a wrapper for

OpenSSL and NSS libraries. NSS is similar
to OpenSSL and is used by browsers like

Mozilla Firefox to enable SSL and TLS
connections. It also provides its own

certificate store. Libvpncommon is another
central library used by all binaries. It

provides classes and functions for the IPC
logic. It can be used to create, send or

validate lPC messages. The next library,
libvpnagentutilities, contains classes and

functions that handle critical operations,
such as host network settings. This

library is only used by vpnagentd. Besides
the binaries and libraries there are a

variety of other relevant files that we
have taken a closer look at. AnyConnect

offers an AnyConnect local policy XML
file. This file regulates various security

configurations. For instance, it can be
used to specify that no further files may

be downloaded or that version updates may
be carried out by a VPN server. In its

default configuration it is very
permissive so that almost everything is

allowed. The file is not overwritten by
updates and cannot be modified by VPN

servers. The VPN profile is also in XML
format: it contains further settings. The

green highlighted line shows an
EnableScripting-tag with a boolean value

of false. Indicating that scripts should
not be executed by the host system.

Profile files are distributed by a VPN
server. And are overwritten the next time

a user connects and changes them. The last
file is VPNManifest.dat which has a binary

data format that contains the version
number of AnyConnect. This file is used to

check the installed version of AnyConnect
before an version update. In addition to

all these files, the message traffic also
plays a central role. The establishment of

a VPN connection is structured in three
phases. Phase one is the authentication.

The user enters the IP or domain of a VPN
server in vpnui. The target server is then

sent via IPC message to vpnagentd. As a
response vpnui receives various system

information back. This includes the
operating system or a whole study.

Afterwards this information and the
credentials are sent to the VPN server

with HTTPS. The ASA returns server
parameters in a HTTPS response. Let's take

a closer look at the request and the
response. On the left side, you can see

the request. It is an ordinary post
request with an XML in which the

credentials are transferred. The
credentials are marked in green.

On the right side we see the response. The
response contains the session token, which

is also marked in green. In addition, the
response contains the URLs to all

downloadable files and the hashes. The
orange marked string is one of the

downloadable files. The download phase is
the second phase of the VPN connection set

up. First vpnui executes the vpndownloader
binary. Then the server parameters from

the previous HTTPS response are
transferred to the vpndownloader via IPC.

The URLs are extracted from the IPC
message and when the files are downloaded

to a temporary directory via HTTPS. The
downloader process informs the vpnagentd

via IPC to move the files to the
application directory. In the third and

final phase of VPN connection set up,
vpnui sends an IPC message to vpnagentd

with the request to establish a VPN
tunnel. Subsequently, the exchange of

tunnel parameters takes place via HTTPS.
After the parameters have been set by

vpnagentd the VPN session continues. Let's
take a closer look at the tunnel

parameters. On the left side, we can see
the request. In the first line you can

observe the HTTP connect method. Usually
this method is used to proxies to forward

the request to the target server. Within
the request, the session token is

specified in the cookie header. This is
the same session token we received in the

authentication phase. The different tunnel
parameters transmitted in separate HTTP

headers. The part marked in red represents
the local IP address of the host. On the

right, you can see a response to the
request. For example, the X-CSTP-Address

header contains the IP address that the
host should apply on its tunnel interface.

In the part marked in red we now also see
the DNS server for the VPN

connection. In addition, the address
ranges that should be routed via the VPN

server as specified in the X-CSTP-Split-
Include header. Now that we have a general

understanding of the application, let's
move on to the vulnerability research. We

have performed an design analysis for
AnyConnect in which we looked at the IPC

messages in more detail. We need to define
certain security assumptions and an

attacker model before we search for
vulnerabilities. This slide shows several

of our assumptions. Cryptographic
algorithms within the application are

considered secure and cannot be broken in
exponential time. An attacker cannot read

or modify messages regardless of their
position, and we assume that the VPN

server does not pursue any malicious
intent and only sends valid messages that

are protocol compliant. We assume a local
attacker who is already able to execute

commands on the system and the attackers
goal is to compromise the confidentiality,

integrity and availability of the system
or application. Privilege escalation

vulnerabilities are also covered since
they allow an attacker to compromise these

three security objectives. Cisco decided
to include an auto update feature in the

application. AnyConnect is able to receive
AnyConnect updates through a VPN server

without any user interaction. In its
default configuration AnyConnect can be

updated by a VPN server that offers a
newer version. From a security

researcher's perspective auto update
sounds promising, right? So let's take a

closer look at the auto update feature.
First, the vpndownloader downloads an

executable installer and the shell script
called vpndownloader.sh. Then

vpndownloader.sh is executed. The Shell
script contains an archive and unpacks

itself to extract a new version of the
vpndownloader. An IPC message is then sent

to the vpnagentd asking it to start the
installer. The vpnagentd does not start

the installer directly. Instead the
vpnagentd calls the vpndownloader with

root privileges, which in turn calls the
installer. Before executing the installer

vpndownloader verifies and validates it.
We got an idea: Is it possible to install

an outdated version through forged IPC
messages? As shown in the picture the

attacker needs an old signed installer and
sends the IPC message to vpnagentd asking

to execute the old installer. The
vpnagentd calls the vpndownloader as

usual, which in turn calls the attacker's
installer. There is no check whether the

installer is more recent than the
installed version. This makes the version

downgrade therefore possible. The
advantage of downgrading to an outdated

version is that an attacker could force
the installation of a version which

suffers from security vulnerabilities and
the attacker could then exploit these

vulnerabilities. We reported the
vulnerability to Cisco's product incident

response team and it was fixed at the end
of September. The vulnerability only

received a CVSS score of 3.1 and was
therefore rated with a low severity. The

vulnerability was only exploitable in the
Linux version. Windows and Mac versions

were already secured against such an
attack. Another functionality we had - we

have looked into is the deployment and
execution of scripts. They call it "Bring

your own script". This functionality is
intended to deploy very helpful scripts to

staff computers. In order for a script to
be executed, it must meet two criterias.

First, it must be located in the script
folder and begin with OnConnect or

OnDisconnect as a file name. Second, the
EnableScripting tag in profile which is

sent by the server must be set to true.
Depending on the file name, scripts are

triggered after VPN connection is
established and terminated. As VPN server

can distribute profiles in which the
execution of scripts is enabled and also

distributes the scripts: these two in
combination allow VPN server to gain

remote code execution on the connecting
clients. This functionality poses a major

problem because humans often need to trust
the university's VPN servers and have no

other choice. But let's take a closer look
at the distribution of the scripts. Here

we see the classic procedure of a script
distribution. In the download phase,

vpndownloader downloads an OnConnect or an
OnDisconnect script. Then vpndownloader

asks with IPC message to move the
downloaded script to the script folder.

The vpnagentd process calls the
vpndownloader, which then moves the file.

We systematically examined the IPC
messages and found a vertical privilege

escalation. An attacker is able to send
the same message to the vpnagentd process.

Any of the attacker's scripts can be moved
into the script directory. If there is

already a script in the script folder, it
is simply overwritten. If the attacker

moves On, an OnDisconnect script while
the user is already - has a VPN connection

open, the script is executed with user
privileges. When the VPN connection is

closed, first unprivileged user can obtain
code execution context of another user.

What bothered us about our attack was that
it is - was tied to conditions. One of the

conditions was that the EnableScripting
tag must have the boolean value "True". We

considered other attack scenarios and came
up with the idea of distributing a profile

ourselves. So we check for the tag again,
but create not only a script, but also a

VPN profile that allows scripting. The
attack works as follows: while a local

user has a VPN session active, another
user on the system creates a malicious

script and a new profile. The new profile
contains the EnableScripting tag set to

"True". The attacker then sends an IPC
message to the vpnagentd requesting to

copy the script to the script directory.
The vpndownloader is then started with

root permissions to perform the copy
operation. Also, the attacker can send an

additional IPC message to vpnagentd
requesting to overwrite the

existing profile with a malicious profile.
Although the profile is overwritten the

settings of a new profile are not applied
yet, because the old profile is still

active. However, we were able to determine
that the new profile is loaded when

there's a reconnect on the VPN session.
Reconnects are actually quite common in

the AnyConnect. If reconnect happens the
new profile is loaded and applied. In our

case, it enables the scripting feature.
After teardown of a VPN connection the

malicious OnDisconnect script of the
attacker is executed with the privileges

of the user running the VPN client. Both
problems were reported to Cisco, but could

not be fixed by the disclosure date.
Although we extended the disclosure

deadline. As of today the vulnerability is
still present with the default

configuration of AnyConnect. Cisco
published this vulnerability with a CVSS

of 7-1, 7.1, which is considered as a high
severity. Because it was published on the

4th of November 2020 without a fix, the
vulnerability got major attention in many

news sites. Various sites reported the
vulnerability. The quality of reports

varied. Some of the articles contained
incorrect information, for example, it was

stated that an exploit was already in
circulation. It is not accurate since we

are the only ones who have a working
exploit and have not published it yet. We

could not find any other exploit on the
Internet either. I think that the way of

reporting - this way of reporting has to
be reconsidered because it has caused a so

wrong assessment of vulnerability. We were
even contacted by some incident response

teams that were worried about their
infrastructure. All vulnerabilities found

and reported are listed in the table
below. The three vulnerabilities were

found by design analysis. Only one of the
vulnerabilities is fixed, according to

Cisco. Especially the Bring Your Own
Script vulnerabilities have already been

published, although no fix is available
for them, a workaround has been declared

to fix the vulnerabilities. By modifying
the local policy file the download phase

can be skipped completely. Since the
latest update it's also possible to

prohibit the download and deployment of
scripts on a modular basis.

M: And what about mobile platforms? Do our
discovered vulnerabilities also apply

here? Let's make it quick. No. Mobile
platforms are lacking many features

compared to the Linux, Windows and macOS
versions. You're, of course, able to

establish TLS and IPsec connections, just
like with all the other clients. But

because features like the deployment of
custom scripts or auto update is missing,

there's no way of using these exploits on
mobile platforms. We are currently having

a look into the iOS implementation of
AnyConnect and therefore want to give you

a quick and high level overview into the
architecture. As we are dealing with Apple

here, serious stuff like the
implementation of the VPN is a bit

different compared to, for example, the
Linux client. If you want to mess with

notifications, add sharing buttons or
create a widget on the homescreen, you

have to use an app extension. Equally for
VPN functionality, you have to use the

network extension framework. The network
extensions contain providers and features

for all kind of network related operations
like for content filtering, DNS, Wi-Fi and

more. If you want to build your own VPN
app, you have to choose between the

Personal VPN, the Packet Tunnel Provider
and the App Proxy Provider. In our case

the AnyConnect on iOS implements the
Packet Tunnel Provider as they are using

their own packet oriented protocol. Here
you can see the contents of the AnyConnect

app package, which is basically a zip file
containing all the executables and other

assets like images, etc.. The main
executable is just called AnyConnect. The

network extension is implemented in the
ACExtension binary. Beside these, there

are also several other app extension
implementations for the iOS sharing and

Siri functionality. So what happens if you
pressed the connect slider? After you hit

the slider, the network extension is
started and negotiation of the VPN session

begins. After a section of network
information like IP addresses, subnet

mask, routes, DNS, MTU and more they are
passed to the iOS system to complete the

negotiation. In the end, you have a new
and hopefully functional tunnel interface

called utun. So new traffic from apps pass
through the network stack until it arrives

at the tunnel interface. It can then be
handled by the network extensions' Packet

Tunnel Provider. Every time a packet
arrives on a tunnel interface, it is read

by the network extension and encapsulated
with the tunneling protocol. Every time a

packet arrives on the tunnel interface, it
is read by the network extension and

encapsulated with the tunneling protocol.
Upon arrival on the VPN server, the packet

is decapsulated and sent to its final
destination. Similar the replies then

encapsulate sent to the client, which then
decapsulates the packet and injects it

back to the network stack. So that's
should be it for the iOS clients, just to

give you a quick overview and highlight
some key differences between the

architectures. We are still investigating
both Linux and iOS platforms, but until

now, we can summarize our findings as
follows: AnyConnect in general is a huge

application with lots of code and also
lots of unused library related code. We

discovered three vulnerabilities through
design analysis. Vpnagentd runs with root

permissions and receives commands or
operations from unprivileged processes via

unauthenticated IPC messages, which is
generally a bit risky. Not all security

mechanisms and patches are actually
included on all platforms. For example,

the downgrade was only possible on Linux
and already patched on Windows and macOS

according to Cisco. The downgrade
vulnerability is not possible on mobile,

as auto update feature is limited to
Linux, Windows and macOS. Similar, the

Bring Your Own Script does also not apply
in mobile, as deployment of OnConnect and

OnDisconnect script is also limited to
Linux, Windows and macOS. Regarding the

local policy file on Linux, our idea would
be to make it as restrictive as possible

and require some kind of opt-in for
scripting functionality. As this would

prevent many attacks but of course, it
would also impact the usability a bit.

Despite the app being available since many
years, we show that there are still many

bugs to find. The introduction of bug
bounties would be a great option to

motivate more security researchers to
check the application for vulnerabilities.

The use of VPN promises security and
privacy for users, however closed source

software opens new attack vectors on a
system as our research on AnyConnect

shows. We hope that more research will be
done on clients in the future and that our

work will pave the way for this. So that
was it. Thank you very much for your

attention and if you have any questions,
feel free to ask.

H: Well, welcome back. So that was the
pre-recording of the super interesting

talk about Very Pwnable Networks. I'm sure
you've seen how pwnable they really are

and luckily, we now have Jiska and Gerbert
and Matthias with us today through the

magic of the Internet. And if you haven't
written out your question yet, please do

so now so we can still answer them. Either
by going to the IRC channel rc3-cwtv on

the hackened network or just posting a
tweet or a toot with your favorite social

media network of choice containing the
hashtag #rc3cwtv this time without any

dash, very important. So our Signal Angel
has collected some questions for us that I

am now going to be torturing the three
people here with. So let's see what you

will say to those. Oh, but I think pretty,
pretty tame, huh? So first question: is

there any page or wiki where this
information can be found?

G: At the moment, it is not published yet.
I think we will publish - publish it in

near future on the GitHub or some similar
platform.

H: Is there any way that people can find
this link then when you eventually will

publish it in the future?
G: I think Jiska can say something to this

J: Yeah so SEEMOO has a GitHub page and

also a Twitter account, so it will be
published. But I mean, there's still a few

things that we didn't like - that are not
public yet. So yeah, and then we would

just make one release not like this CVE
and that CVE, but like all at once.

H: Yeah. Make - makes more of an impact
this way and also better, better

disclosure. I like that. And the next
question is: will this VPN event only be

about Cisco? So yes, you've only looked at
Cisco, right? In this case. Um, maybe you

can tell us something if maybe you have
looked at other VPN vendors as to

something that other VPN vendors might
have an issue with as well? Maybe.

M: Yeah, we've done this research as part
of a master's thesis, and therefore it's

only about Cisco AnyConnect and yeah, we
did not have the time to - or yeah. Yeah.

To look at other VPN services, just for
the AnyConnect.

H: Yeah, the typical Master's view writing
it hyped up on coffee for the last few

weeks before the deadline. Yeah, I can
imagine that you focused on Cisco there.

Uum, another very good question: Are these
vulnerabilities also present in other - in

other AnyConnect-like clients like the
ones integrated into NetworkManager in

Linux? I think they're talking especially
about OpenConnect. Yeah, that's just

coming in. Umm, we talked about this
before a little bit so you probably have

something to say about that.
G: As far as we know there's - in

OpenConnect there is no scripting -
scripting feature enabled or integrated.

So we would say this kind of attacks are
not yet possible, but uh -

M: That would be possible if someone is
able to check this and, yeah, have a look

into OpenConnect too, yeah.
H: Hmm, yeah, not yet known to be

possible. Let's - let's say it like that.
You never know. Any other questions from

chat, from Twitter or Mastodon? Now's the
time. Give out your questions. Otherwise,

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

hackened IRC network or post a tweet or a
toot with the hashtag #rc3cwtv this time

without any dash. Umm, do it now, and
hopefully I will still catch this

through the magic of the Signal Angel that
is collecting all this information for me.

And yeah, maybe anything that you want to
add or any other new topics that you're

working on, something that might be
upcoming. Maybe we can get a sneak

preview. I'm sure you're still continuing
the research there - and

J: Sorry I needed to unmute myself. Not

spoilering yet but I mean, the issue like
just looking into one VPN client it's

also, if it is proprietary, then just
reversing is a lot, a lot, a lot of work.

I mean, I can tell you a story about like,
looking into binaries for months, and so

it doesn't really scale to look into like
10 different clients, at least if you want

to have meaningful findings.
H: Yeah, but like you don't have any any

other plans to, you know, look at any
other clients that get any requests or any

triggers that would point you there. Maybe
having a new phone and a new client and

noticing new strange things? No? - Okay.
G: Not yet.

J: Yeah.
G: But, but yes, Matthias is still working

on it. I think he will find something in
the future. M: hopefully.

H: Yeah. Yeah. I guess that's pretty much
all the last questions, except one: There

are two shadows behind you Jiska, is that
the shadow cabinet?

J: No, no, no. I just have multiple lamps
here. So -

H: Yeah, yeah, it's funny everyone &lt;??&gt;

J: At least it's only showing my shadow
duplicate. Not - not me.

H: Yeah. But we're quite lucky that at
least in this talk, the connection seems

to be working fine. We've been having some
issues here. Yeah, but that's great. If

you have any other questions, I think
we'll wrap it up here not to keep you

around much longer. I'm sure you're eager
to jump around the rc3 world, and if you

have anything else, maybe you can join us
in the IRC later. If there are any other

questions, maybe they will look there for
a short while or I will forward those

questions. Right then.
J: Thank you.

H: I thank you very much for the super
interesting talk. I learned something new

about the VPN client that I came into
contact with during my work time as well.

So interesting for me too. And yeah, let's
keep it at that.

<i>postroll music</i>

Subtitles created by c3subtitles.de
in the year 2022. Join, and help us!

[Translated by {Iikka}{Yli-Kuivila}
(ITKST56 course assignment at JYU.FI)]