[Translated by {Iikka}{Yli-Kuivila} (ITKST56 course assignment at JYU.FI)]
*33C3 preroll music*
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&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&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 <??>
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.
*postroll music*
Subtitles created by c3subtitles.de in the year 2022. Join, and help us!
[Translated by {Iikka}{Yli-Kuivila} (ITKST56 course assignment at JYU.FI)]