Dear viewer, these subtitles were generated by a machine via the service YouTube and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/3025 Thanks!
[Music]
all right then it's my great pleasure to
introduce our next talk finding
vulnerabilities in Internet connected
devices I think after this talk you'll
never look at polyphones and Conference
uh microphones the same way probably um
Pascal sener and kristofh wolf are going
to talk to us about um how they've been
um hacking these devices finding
vulnerabilities in them um our two
speakers are both Berlin based um um
Internet Security and web analysts and
um I think they've been looking at web
security for a while so I'm very curious
to see uh what they did with these
phones and why I'm never going to have
an Internet connected um microphone
anywhere near my workplace I think
please welcome Pascal and
[Applause]
K all right uh thank you hello everybody
and thanks for joining our talk today my
name is pascy I'm working for modero as
security analyst and with me is Kristoff
we're both focusing on web security red
teaming and mobile iot web penetration
testing
basically this talk will be about how
you can find vulnerabilities and all
kinds of Internet connected devices and
if we talk about internet connected
devices we mainly mean iot embedded
systems uh webcams conference systems
phones really anything which is smart
nowadays so we wanted to have this talk
uh because we wanted to show that you
can have good results in device hacking
um without the need of specific Hardware
EXP expertise or soldering skills these
are obviously super helpful but we will
just try to avoid them because they
require good Hardware knowledge and
specific tooling which to most beginners
is not available and instead we will
focus on the
software and we also want to show that
all bus are hard to find or require deep
technical skills so basically anyone can
start with it and we will cover
different techniques and basically all
kinds of skill areas and lastly
hacking iot and embedded devices is just
a ton of fun and we really want to
motivate people into getting into
it so this will be the agenda for today
uh we will talk a little bit about our
research Target which we will use as an
example today uh the pulley conference
speakers and telephone systems then we
will talk about an research process that
we apply to these kind of devices and
that hopefully you can use as well and
in the ends we will talk about our
result but also how you can basically
show the impact of your results after
you did the research and hopefully in
the end we will have some time for
questions so there is already a tons of
good beginner talks out there and so we
really wanted to do things a little bit
differently and that's why we need to
talk about the company
poly py or polycom is a very popular
vendor for video phone and conferencing
Hardware and was bought by HP in
2022 um it's a super interesting Target
because they have really interesting
feature set they run on Android they
have support for teams Zoom Skype a
native zip client and they have a very
restricted launcher meaning you cannot
really uh leave the initial application
it's it's supposed to be fully locked
down you don't have any support for play
store apps um and there's a custom
settings menu which basically prevents
you from using the normal Android set
settings and they have a lot of
different interfaces they for example
have l or Wi-Fi but also Bluetooth and
can be configured through a web
management
interface which makes their feature said
really interesting for large Enterprises
because you can configure a bunch of
these devices very quickly and in summer
this year a client asked us to look into
these kind of devices basically the two
one you see on the slides the trio 8,800
is a conference speaker which you can
put in your meeting room and the CCX is
a smart telephone with Team
support and we found several
vulnerabilities uh in these devices and
we will um talk about them today we have
reported them to the vendor and a
coordinated disclosure process and the
process was was quite nice and the both
pulley and HP answered super quickly
very transparently and took it seriously
right from the beginning so we want to
say thanks to them for that and uh also
in the end we will link the disclosure
report if uh any one of you has these
devices in use you may check it
out so during the disclosure it turned
out that not only the two devices we
looked at were vulnerable but actually
there's a whole bunch of their systems
which is vulnerable to that and all of
them should be fixed or at least there
should be mitigations out by
now and with that we have the very I
would say rare opportunity that we can
give this introductory talk but we can
also give you real world examples for
the vulnerabilities that we want to look
into and that we want to search for and
we think that's great because it really
illustrates uh the methods itself and if
you want you can buy a device for
yourself and do a jailbreak or solve the
challenges like in a CTF or
something all right now Kristoff will
start to guide you through our research
process and show you how you could uh
basically find vulnerabilities like
these
so um first up we'll introduce uh two
important Concepts which we use
throughout our talk the first one is
basically that vulnerability research on
a very high level is a rinse and repeat
process in the first step we enumerate a
part of the attack surface of our Target
we will then evaluate any potential
issues and uh at last we will exploit
any weaknesses that we find and then in
the next step we will broaden the attack
Sur surface we do this either when we
get stuck or or when we have exhausted
all of our options and we can do this by
either looking at new features which we
haven't looked at yet or by using some
newly gained access from one of our
successful exploits and then we will
rinse and
repeat um today we will show you the
vulnerabilities which we can divide in
basically these two uh kinds um there
are business logic vulnerabilities and
Technical vulnerabilities on the
business logic side we can exploit
actual design flaws in an application um
by using the device in a way that
developers did not really think about
they usually do not require much
technical knowledge uh but rather
thinking outside the box in the context
of the device or application that your
hacking and that makes them especially
interesting for beginners um because
yeah you can get pretty easy results
without do doing a deep technical dive
and an example for this kind of
vulnerability would be a web shop where
you can maybe apply the same discount
code multiple times in a row to really
make something super cheap um and on the
other hand we have the technical
vulnerabilities these are usually the
programming failures the one you have
probably heard of before something like
a buffer overflow or an SQL injection
and we will see more examples for this
later on in our
talk um our research process um will use
the concepts we just showed you and this
will be our research plan we will first
use or rather misuse the device we will
then enumerate exposed Sur services
veryify and learn from already known
vulnerabilities and then later on we get
to do more advanced topics like fuzzing
web API pen testing and some reverse
engineering but first up we will start
using our device and we do this to
actually getting to know our Target so
that we know what it does and what
functionality it offers we really want
just just at this phase explore the
device just visit every menu use all the
functionality we can find just being
really curious uh users of the device
and trying to find out what can it offer
to us it's also usually very helpful if
you read the available
documentation um or a manual and just in
general find out anything that you can
about the device in our case with the
pentest assignment we had the customer
was using the phones in a somewhat
unprotected area and so to them the
physical attack Vector was very
important so naturally this was one of
the first attack Services we looked at
so we as Pascal said there's a rather
lock down interface which you get by
default and we wanted to escape this
what you call normally a kiosk mode um
for example if the phone is in micros
Microsoft teams mode then you cannot
actually ever leave the app so all the
device settings are inside the teams app
and there's not like something like a
home button to get to a home screen you
just are stuck in the teams app and when
you're not in teams mode you have like
somewhat of a launcher but you can only
launch the applications for which the
device has been configured before so we
now want to leave this restricted UI to
maybe access a browser or in maybe even
install a malicious app and to do this
there are various tricks we can use so
one of the examples would be kind of
obvious but swiping in from the edges
maybe see if we can get maybe the
notification tray find a uh find a
button that gets us to the settings or
something um on the other hand we can
also try to open other applications uh
pretty good trick for this is usually
trying to long press on images see if
you can maybe share them to another app
then the other app opens uh Al also you
can also oftentimes start web searches
for example if you hold if you press
long on text and you get a context menu
you can say web search then the browser
opens up and then you have access to the
browser and if you get to the browser
you can then use this to maybe download
files even executables and run your own
code or at least browse the file system
or maybe through custom protocols like
mail to you might be able to open up the
mail
application something else to always
check for is booting into uh different
modes for examp example like Windows
save mode or when you want to get to the
bootloader on Android you you usually
have to press one of the volume piece
while booting so you can try while
booting up pressing any combination of
keys and see if you get different
results than booting
normally um also in general you want to
examine device physically very closely
you really want to find all the ports
all the buttons that they have and
especially with the ports if there is a
USB port you can usually do all kinds of
shenanigans where you connect different
devices and see how the device you are
hacking reacts you might want to attach
something like a f drive to get a file
access or a printer to get a special
dialogue and also you can usually
connect a keyboard and that is actually
something we did and we connected a
keyboard to our CCX VI phone and then we
tried all kinds of key
combinations um and Android has some
built-in keyboard support so there are
some default key combinations that you
can use for example alab usually
switches the frontmost application and
when we tried to in the CCX and teams
mode it was kind of a strange Behavior
which you can see in the screen
recording um so here we see the normal
teams app on the phone and these are the
basic settings that you get so it's
basically all included in this in this
teams app but now when you try to hit L
tab once we get this black screen and
kind of not really getting there but if
we hit it in quick succession we
suddenly get to this screen which looks
completely different than the teams app
and this is some native app that was
apparently running behind the teams app
and which we can now get to this allow
ows us at least to see a little bit more
than the normal team settings we get
some special Diagnostics uh and can
actually execute ping and Trace routes
in the uh in the
network um and in general uh we can also
take a look at business logic
vulnerabilities here these as I said do
not require much technical skills and
here is a great example of this kind of
vulnerability so this is on the trio the
trio settings look pretty similar to the
ones that we just saw UI wise and so
they usually have an admin only area so
you can browse some Diagnostics without
knowing the admin pin but for actually
get changing important settings you need
this administrator password and this you
see the screen here where you have to
enter the password and this makes sense
if you think about the trio as a
conference speaker it will be just
sitting in your conference room you
might have guests over and anyone could
just mess with the device either
intentionally or by
accident and so what we did being
curious users of our device we will just
look around the menu where we don't need
a PIN and then just see what we will
find and we did indeed find something so
in this status SL Cloud status page we
found this NE entry called registration
code and there it said okay your phone
your Trio is unregistered and said this
is your code you can go register it at
lens. poo.com
and so we did we got went to our browser
went to lens.com created a free account
and registered our device and we just
needed this pin we just got and the name
that we could choose after we we did
this we got this pretty looking
interface where we saw our devices
details local and public IP address the
firmware version but there's also the
settings area down down below here and
this actually allows you to completely
manage device this includes the harmless
settings like the ringtone but you can
also just set a new administrator
password
and you can also launch a packet capture
if you want to see all the packets that
are sent received by the device all
remotely from your
browser and there's even another handy
function in here in this uh more actions
area we have this uh menu Point called
initiate call which gives you dis need
dialogue where you can just enter any
phone number and the device will call
you so you can listen in on any
conference room where you have done this
before and then just have the device
call you and you are on speaker phone
you can just listen in you can talk to
the people um however you
want and this is a business business
logic vulnerability because at no point
in time we had to enter our
administrators pin we didn't know it we
just had access to device we saw this
code we used it and now we have the full
admin
capabilities the only preconditions for
this is that of course you need physical
access for the device which is might be
tough the device must not yet have been
registered before and it needs to have
network access to poly service because
otherwise you cannot enroll
it so next up we will enumerate any
exposed Services uh and um this is
pretty similar to the um exploratory
phase which we did physically but in
this case we will actually use some
tooling to check what ports are open
what services are running on the device
and um just find out what is going on
there and to use this we use uh tooling
nmap is very very common um but there
other options exist like nucle for
example which can do also some service
enumeration but it's also a
vulnerability scanner so you might find
some PR already known vulnerabilities
and some components of the
device um if you're a beginner it
probably makes the most sense to just
focus on the protocols or service that
you know already for example if there's
a web server running there and you have
some experience with that then you can
check it out uh if you see file shares
then you will uh you might want to check
out these anything that you know already
will probably be a good first start of
course the more complex protocols might
offer also more Tech Service as they
usually also for the developers harder
to implement
there are no there are n no pre-existing
libraries to use and so this might
require a little bit of a deep dive but
it can also lead to good results in the
fun challenge as
well so on our device as you can see on
the top here we found a port for for
free open and there was a web-based
management interface which is I think
very common for these kinds of devices
and in our case it is first protected by
a password prompt where you need the
same password which you need for the
settings
um if you should ever be faced with that
login screen the default user password
is 1 123 and the default administrator
password is
456 um yeah and here again we enter
another iteration of our enumerating and
bro enumeration and then broadening the
attack surface so we again just like we
did in the menus before go curiously
exploring all the functionality trying
to understand the business logic putting
on our hacker glasses seeing what
functionality might be interesting to us
as an attacker and how can we get there
in the UI and also think about what
protections are in place and
where and so we go looking around and we
come to this software upgrade screen and
um then we look at this look at this
dropdown menu we see this is not really
about software upgrades you can actually
do software downgrades
here and in generally this is not a good
idea because usually these updates also
do fix some security issues right so um
yeah this is called pack protection if
you protect this and this is obviously
missing here um and as you will see uh
in a couple slides these older firmware
versions with non vulnerabilities will
come in
handy uh another thing that we found was
that when we wanted to change the
administrator password you needed to
enter your old password which is pretty
sensible security boundary here again
there is another need management feature
which is configuring device by uploading
the XML format which just sets all the
settings that you want and this XML file
you can just upload without knowing a
password but you can also set the local
administrator's
password again another classic business
logic vulnerability they figured at one
place we need this protection you need
the old password to change it but for
the configuration they just did not
think about
this our next step now is to verify and
learn from already known vulnerabilities
for our devices and you should always do
this uh as early on as you research as
you can
because it really can give you some good
hints where you want to look for any
vulnerabilities and also similar devices
might also have similar
vulnerabilities for example uh um if a
uh if we have a broad catalog of devices
from a company like poy then there's a
good chance that the that the code
between these devices is at least
somewhat shared and that the
vulnerability that you have in one
device might also apply to your device
so always check if any vulnerabilities
for similar devices maybe uh if you're
able to reproduce this on your own uh
here we also list some common sources
where you can check for known
vulnerabilities in our research we found
a very cool blog post um which actually
talks about an authenticated remote code
execution in the polycom tri 8,800 which
we had uh to look at and for us as
attackers remote code execution is
really just the Holy Grail this is the
highest impact our attack can have
because if we can uh if we can execute
our own code we can do whatever we want
with the device and this blog post also
revealed some cool and to us previously
unknown attack surface which we hadn't
heard about yet because there is an
undocumented Diagnostics tet which you
can also enable via the XML
configuration and this they then use to
execute code on the
device so now that we've heard about the
taet we will again broaden our attack
surface and dive into our exploration
phase there we enable a tailet server
using the configur fation file and in
our end map we can see that Port 1023 is
now
open so we then connect to the Tet where
the user is always polycom and the
password is the administrator password
you had set and then you get this shell
with some predefined commands and lots
of these seem very
custom um and they allow you to do stuff
like seeing the currently running
configuration as XML but also see the
internal CPU load uh basically lots of
Diagnostics
functionality
so in the blog post they found that some
commands are basically just passing it
their arguments to a to a shell which
will then execute the command for
example the Ping and so what they did is
they did a command injection using the
semicolon which in most shell separates
two commands in the same line so they do
uh they ping something and do semicolon
ID then you will see first the Ping is
trying to be executed it fails and then
you see the output of the ID that is
showing us that our Command is actually
run as root user so that the highest
possible
Privileges and um then in the blog post
they then use this to enable ADB which
is an Android debug feature it basically
gives you apart from other things a
shell on the device which is just
unrestricted so on our Trio on a new
firmware we couldn't reproduce this so
we did the same thing you can see down
below we execute the Ping then we call
an ID and it just says the the the error
for the DNS name resolving is now
handled and it fails completely the ID
is never
executed but a kind of common thing is
for vendors that they only fix the
security issues exactly where they are
found without fixing the underlying
issue systematically so we thought hm
what other commands do we see that might
also be just passed to a shell and then
we found the top command and we found it
works the exact same way
still
um
[Applause]
yeah as you can see this is still
injectable it is still running as rude
and we have now code execution as route
on our Trio on the CCX we couldn't
actually do this the same way because
there they have a newer major version
for their firmware and apparently there
they actually fix this in a diagnostic
CET where they pass the command check
for any unwanted characters like
semicolon and then they just don't uh
don't execute the command but in the
case of the trio we get got full control
over the vulnerable vulner vulnerable
device if we know the administrator's
password and uh now it's my pleasure to
hand over back to Pascal who will tell
you about our more advanced topics like
[Applause]
fuzzing okay so now that we already
dived into the technical vulnerabilities
we want to talk a little bit about
fuzzing so software nowadays is really
complex and one might even say it's
getting too complex to completely
manually ensure that it is bug free
because the code size constantly
increases but our manual efforts to fix
every issue doesn't scale in the same
way and we as ATT techer have a great
Advantage because we only need basically
one single mistake uh that we can
exploit later on and fuzzing is a
technique which helps us detecting such
cases that were overlooked in the
software development process we
basically tried exploit this code
complexity um by leveraging brute
force and fuzzing is especially
effective for languages which perform
unsafe memory operations like C or C++
because there we can look for um memory
Corruptions overflows or any issues with
pointers and if you find an issue this
uh in the best case results in a crash
but in the worst case in an exploitable
bug so this is this is a high level
overview of the fuzzing process in the
middle we have the fuzzing engine or the
fuzzer and the fuzzer gets supplied with
uh user input the so-called seats and
with these seats we try to have input to
a Target program which basically cover
as many code path in the Target as
possible the fuzer will take our seats
mutate them randomly uh in different
locations and run them against the
Target and then then it will observe for
interesting
behavior and this is done as fast as
possible so we really try to test a lot
of cases in a quick
time the question is what is an
interesting case so this might be a
crash or a timeout or in the best case a
memory corruption and then we can look
into these cases later on and see if
it's an exploitable bug or insecurity
issue there is a major improvement over
this kind of basic fuzzing approach
which would be coverage guided fuzing
and in that case we or the F has a way
to detect how many code paths were
already covered in the
Target and that really gives us a better
indicator on what kind of mutated seeds
are interesting and we can them put them
back in the seats and start the process
from a new if we get greater coverage uh
we basically see more of the program and
have a higher chance to find a buck but
Sly for this talk we would stick to a
basic fer um it is mostly enough for iot
devices because there you can usually
get quick wins but if you're interested
in coverage guided fuzzing we can highly
recommend uh the talk fuzz everything
everywhere all at once which was here
yesterday and goes into a lot more
detail about Advanced
fuzzing so how do we go about building
such a fuzzer uh we knew the web server
was uh written in C++ and therefore we
thought it's a very fruitful Target for
fuzzing attempts and our go-to for this
kind of of very simple and basic fuzzing
is buas we have linked it
below because buas is a general Network
protocol fuzzer which we can really
quickly adapt to all kinds of
protocols uh there's a lot of examples
on GitHub so you can just look for the
protocol you want find the um a good
example and then basically fit it to
your test
case and there's also a great
introductory blog post about it in
German uh by inside a tech logic which
we also have linked here if you're
interested
so what you can see here is a normal
HTTP request to the device to the
management interface basically the
device will pass the session cookie and
then it will check if the authentication
off us is valid and from experience we
know that paa are most often a very
interesting Target for fuzzing because
there you can just do a lot of
mistakes so how would we go about fing
this
request so we basically trans transform
the request into such a test case um we
take the legitimate request and then we
Define which parts of that we want to
fuss so everything which is appended
here with the static uh will not be
mutated and the areas which are marked
with string will be mutated by buas
string mutation algorithm and with this
test case we specifically try to fuss uh
the cookie passing
implementation uh we want to have this
static Parts because we really want the
device to pass our package and so
sometimes we need some things to be
static to get to the point where we can
actually fuss the right the right
point the fuzer then creates random
requests and they might look like this
so for example here the fuzer created a
request with a lot of a and the session
cookies value and if the device would
crash now we might have a buffer
overflow or something like
that
while the fuz is running we have this
kind of output here we see um different
eof cases which the further identifies
as interesting because they might
indicate a crash or a Timeout on the web
server and now if look if You' look into
such a test case we uh I hope it's big
enough maybe not but um in this specific
case for
example there is no actual value for the
cookie so cookies are always sent in
value Pairs and in this test case
there's no equit sign and no value and
so we thought okay let's reproduce a
minimal working example and see if
there's an actual underlying
issue so the window on the right here
shows our connection to the debug tet
and we Ed this to basically check if the
target is still
online and then we just took a normal
request and modified it by removing the
session cookies value so we just stri
the equal sign and the value and and
immediately the device crashed and
rebooted so it's a super quick and easy
bug to find uh we didn't need to wait
long it just took a few minutes and now
as an attacker we could exploit this by
for example just sending this request in
a constant Loop and the device will
crash and take three minutes to reboot
every
time so the big question is what is the
root cause for that and we investigated
it looks a little bit like a memory
corrupt memory corrupt
and sometimes such a crash um is
exploitable with binary exploitation
techniques and it's worth looking into
that if you have the time during an
assessment or in your private time um we
wanted to make the most of this research
and we only had one week so we basically
um reported as as is because if there's
more to be found this is already enough
for the vendor to know there's an issue
they need to fix and if anyone is
interested looking more into that and
building a fullblown exploit then let us
know okay now we already talked about
HTTP so it's a great uh transition to
actual webon API pen testing so this is
always a big part of our attack plan
because basically all kinds of Internet
connected devices use HTTP in some form
or another there's like these Local web
management interfaces that we already
saw but a lot of devices also connect to
some API on the internet which maybe
allows to configure the device or update
the firmware or store
data and we need a active machine in the
middle position to see and modify the
HTTP
communication and there's a lot of tools
for that we usually use BB there's a
free Community Edition but there's
ultimate M proxy which is also great and
completely free and open source but you
can also start with your browser staff
tools if that's something you want to
work with and once once we have this
setup ready we basically perform a
normal web penetration
test and if we say that we mean testing
for vulnerabilities like SQL xss or
command injections CSF takes idors um
authentication authorization bypasses
and so forth and we could talk a lot
about that here but I think there's
already loads of great resources online
and you will probably find something um
interesting to read about that somewhere
else um if not please come to us and we
can give you some hints
so as we said uh we always look at the
authentication process and especially on
iot
devices let's say developers get very
creative in implementing non-standard
orth
methods and for example here we
performed several authentication
attempts and extracted the session
cookie the device sends us and we did
this with the intention to see if the
session cookie is maybe in some kind of
another predictable and normally we
would expect every session cookie to be
unique but here obviously something is
really wrong because there's a whole
block of tokens which look the same so
we were sure we spotted an issue here
but question is now uh basically what is
going wrong and that's quite hard to
analyze and understand if we only have
this limited blackbox information so at
this point we again need to BR the
attack
surface and in this case we will do so
using reverse engineering which is also
the last Technique we want to talk about
today so reverse engineering basically
is the process of understanding how
software hardware systems working by
analyzing the individual components and
then we try to reverse them back to a
planning phase object that we better can
work with so for example we have a
compiled binary and then we compile it
back to the potential source code to see
what's going
on and a good starting place for any
kind of device is the firmware because
if we have an actual insight into the
software which is running on we can
always better test we can dynamically
test and verify Behavior which looks
strange and often we can even find
hidden features of
functionality uh a lot of times there's
also some leftover developer tools which
are great for us and yeah we always see
hardcoded
secrets so how do we get the firmware
like in the best case we just downloaded
from the vendor's website that's most
often possible uh interestingly enough
since we did our disclosure the pulley f
is
missing in other cases we might use a
machine in the middle set up between the
device and its back end and intercept
the F update process and extract the
binary from that and sometimes you can
just get creative so for example once we
had a firware update tool on
Windows and we downloaded it downloaded
the firmware into a temporary file
transferred it via USB to the device and
then it got immediately deleted and then
we just removed the user's permission to
delete files so the firmware basically
stuck after the update process and then
we could unpack
it yeah and if the firmware is not
signed or the signature is not validated
then at this point you can also of
obviously tamper with the firware right
you could modify it and adapt it to your
needs but we really recommend to do this
in the end because you might break your
device and that's not good if it's in
the middle of a
pentest if you have an unknown binary
format uh you can use binwalk it's
basically walking over the file looking
for known file signatures and it's
extract these from the binary
file but we had an Android F image here
and there's a lot of existing tooling to
unpack the firmware and once it is
unpacked we can basically walk the file
system and see what we can find
there um we can use Java decompilers to
reverse any Android application files
back to its initial Java source code and
with jedra for example we can decompile
executables into a somewhat readable
representation of the initial source
code and also we can look at the file
system and see if there's any startup
scripts or Services which are most often
very interesting as
well so reverse engineering is very
timec consuming and it takes some
practice um but you shouldn't be
discouraged because it you get better
really really fast
and also you can always see if someone
else did already the work that you are
planning to do so there's a like really
big jailbreaking and routing Community
for all kinds of android devices and a
lot of people already did this kind of
things with the device
already and with a little practice you
will get better quite fast so there's a
practice challenges called CMEs which
are basically small reverse engineering
challenges uh that you can work with and
most often it's not necessary to
understand everything so you can just
focus on smaller sections uh that seem
important to
you so this is the piece of C code J
will show you for the session cookie
generation and now we can walk through
the code together and see where this
issue stems
from so here in the bottom we have a
variable which we call random string
pointer which will basically hold the
session cookie in the end and now we can
actually skip most of the part of the
code because it's Det istic we can just
Implement that ourselves and we want to
see where is the randomness introduced
into the
token that's actually here and this Rand
call and now what we always do if we
have a call where we're not quite sure
what this does we check the Man pages
and Rand doesn't actually return a fully
random number but a pseudo random
integer and if uh the Rand can be seed
by the srand function we basically give
a number to the SR function and then the
sequence of the numbers afterwards is
always exactly the same if you have the
same seat
value so here we see the Asen call I
talked about and it's actually seated
with the
time and if we check the main Pages for
time we see that it just Returns the
number of seconds since the EO and
that's that's great for us as attackers
because the resolution is way too small
and that's actually something we can
fully predict um and we can really know
what token is being generated so just
putting this together basically for
every second uh there's exactly one
session token that will be generated and
it's the same for all po devices and
this is obviously something which we can
exploit so this is a successful
authentication attempt against the
device and the web server will return
its time uh which will allow us to
basically have the the number for the um
sren call and this is the session cookie
which the web server will
return and now what we did is we just
reimplemented uh the the code I just
showed you from earlier and can supply
it with an arbitrary asant
seat so if we do that we basically
generate the exact same session cookie
and now the question is what what can we
do with that so in short we can steal a
locked in administrator session for
example we could just create all
authentication tokens for the last two
hours it's only 7,200 and when then we
check programmatically if any of these
sessions are valid and if yes an
administrator had logged in and we can
take over the session another approach
would be to just constantly try to log
in with the session token from about 5
seconds ago and once an administrator
logs in we can overtake their
session okay now we've seen a lot of
different
vulnerabilities and vulnerabilities are
most often measured by by the impact
meaning that we as hacker or as pester
really need to be able to properly
showcase what impact we can achieve and
what is of often overlooked during this
process is that the vulnerabilities
don't need to stand on their own so you
don't need to basically show the one
vulnerability you found you can also
cleverly combine several issues and that
might be um might be able to increase
the overall impact of the individual
ones so here on the we have an
unauthenticated attacker with network
access and on the right our goal which
is the remot cord execution and we don't
have a single issue which allows us to
do this but by chaining the
vulnerabilities we uncovered today we
can actually do that so starting from
the back we know for the rce we want to
exploit the command injection we talked
about this one has two big requirements
we need a vulnerable firware version and
access to the debug tet and let's talk
about the last one first so so for this
we need an enable debugging tet which we
can do with an active administrator
session by just importing the
configuration file and we also need to
know the administrator password and for
this we also have a bug because if we
have access to the administrator session
we can just import a
configuration which overwrites the
password so the vulnerable firmare
version there's actually pulley devices
which are vulnerable right from the
start like the 30 8,800 but for the
other ones we just perform the roll back
uh via the web
menu so for all of this we need an
active administrator session but we
already know how we do that that is the
administrator session
prediction so basically the attack plan
is clear we just constantly try to take
over a session once we got one we
downgrade the firmware if we need to
then we import a configuration file
which enables the debugging tet resets
the administrator password and then we
can exploit the command injection and we
could even speed up this process if we
just send our crashing HTTP requests
every once in a while so an
administrator might be looking into
[Music]
it so if you do this with all the
discovered vulnerabilities uh there's a
ton of attack path and we know this
diagram is messy so don't you don't need
to try to uh basically understand all of
it but we just want to show that the
most severe issues that you can find
most often don't stem from a single bug
but from multiple bugs so just don't
stop if you find something interesting
because if you have multiple interesting
things it might be way way bigger impact
so one example would be here if we have
a tree or 8,800 we kind of go completely
different attack chain if we have
physical access uh but no credentials we
can just do the lens enrollment we
talked about earlier and once we did the
lens enrollment we can set the
administrator password and enable the
web server then we can connect to an
attacker controlled Wi-Fi and we don't
even need to downgrade the firmware
because they're vulnerable from the
first place and then we will um
basically exploit the command injection
and have our remot code execution as
well so this probably a little bit
confusing and therefore Kristoff will
walk you uh through a demo now
[Applause]
so now it is time to for us to
demonstrate our Tech chain the one
earlier from where we stole the
administrator session to get in code
execution on the device and we do this
by uh showing showing you our exploit
script and to really show the impact of
us being able to execute code on the
device we will uh re use an existing
tool we found on GitHub that will allows
us to forward an Android phone's
microphone input to our own laptop and
then it's basically a microphone on the
laptop which we then can listen to in
real time and record as we will uh do
right now and we will use this to listen
in on me while I'm having a perfectly
normal video conferencing on my computer
with a CCX 400 sitting on my desk I
really hope the audio will be
working so on the left
here on the left here we will have our
proof of con script on the right you
will see the administrator interface
where we will now log in our script
constantly tries to take over the
session with the session from a couple
seconds ago which has just worked here
we have a valid session and we'll use
this now to upload a malicious
configuration enabling the password and
enabling the debug tet mode now that we
connect to the debug tet mode using the
password we just set we find that the
device is vulnerable to the command
injection and we can execute cod as root
if the command injection would have been
patched at this point we could use our
uh downgrade vulnerability to downgrade
the firmware to a vulnerable one and now
we use our Command injection to
basically enable stage two which is set
up ADP and forward the
audio got it oh yeah the new phones are
great by the way apart from that not
much from my side but be aware that we
changed the default password for new
users to winter at 1
123
so so glad that the audio worked um so
um and this just leaves
[Applause]
us uh and that just leaves us with a
fully jailbroken device we can now do
whatever we want with it we can pass
time at the office by running d
but uh we could also for example attach
the attack the attached network from the
compromised phone or try to fishal user
credentials by the way maybe pop up
something looking like the teams app
asking for the teams
credentials and um yes this pretty much
concludes our talk you will find the
advisory page in the top uh right and uh
our contact information is also here on
the slide that's that's it from
us
all
right thanks so much up until this point
we'll have plenty of time for questions
so if you have a question in the room
please come to one of the four um
microphones uh line up and we'll make
sure to get all questions
answered if you're leaving the room
already please do so as quietly as
possible and I'm not sure if our signal
Angel showed up at this point and maybe
has questions from the internet but I
don't see a hand waving right
now all right microphone number three
please hello thanks for the great talk
was really really cool to hear about
that um I was wondering I think I missed
it maybe like why were the session keys
after all so similar
uh it was because we did a basically a
few requests in a second and for every
second there's only one session cookie
so if we did like 10 requests in a
second then we have actually the same
session cookie got it
thanks all
right I don't see any other questions
right now so then I think we'll conclude
the talk thanks again to Pascal and
[Music]
Stu