Waiting..
Auto Scroll
Sync
Top
Bottom
Select text to annotate, Click play in YouTube to begin
00:00:00
hello everyone it's a pleasure to be here on stage and tell you some stories about mobile networks mobile network security it is a very it is a long
00:00:14
journey we we started about nine years ago and we the first radio intercept attacks then discovering other implicature threats and then so7 finally
00:00:27
in 2014 since then I think no major issue no major vulnerability was discovered or published and well in this in this years
00:00:40
we continue to to do research and analyze the new technologies that have been deployed around mobile networks and today we are going to see a new one that was supposed to fix some of the issues
00:00:51
of the previous technologies and well the outcome is that this technology probably did not yet reach that goal so what happened this day is really about
00:01:04
one week ago Google started pushing very hard together with other mobile operators worldwide a new technology on your mobiles this technology is called RCS and it's going to replace and
00:01:18
enhance your messaging and calling experience with mobiles this is something similar to what's up iMessage or Skype it's just going to be integrated in your phones by default so
00:01:30
you don't need to install any other application it will be there and now the question will this technology solve all those issues that I mentioned intercepting over the radio as the seven
00:01:42
issues and so on well not yet okay and today we will see quite a bunch of vulnerabilities we found and also we will see what are the possible
00:01:55
mitigation for those our abilities let's start giving a bit of a recap of all these vulnerabilities that I talked about and be basically aligned to what we defined as intercept for example or
00:02:09
in tracking users okay so we grouped all these vulnerabilities into five areas you see them there the first is intercept is pretty easy to understand it's just basically being
00:02:24
able to intercept calls or SMS or even data it can be done locally so close to the victim or remotely for example using so7 so I in a in a
00:02:36
remote country can sniff your calls and your SMS far away not only we can intercept calls and SMS we can impersonate this means I can start a new call on your behalf or send an SMS on
00:02:50
your behalf pretty dangerous for for certain use use cases and then what else we can track users this means locally or remotely I
00:03:01
can have an idea about who is around me and I can track them quite precisely wherever they move around the world then we follow with fraud pretty interesting
00:03:14
for mobile operators especially fraud means use the service without paying for the service or user service and charge somebody else for the service and you get the revenue out of it and finally
00:03:28
the OS this is something we don't see very commonly in the wild but it's possible to create a do s for a single user so I could make your mobile unreachable or I could make the whole
00:03:39
network unreachable so this was just a recap of the five attack possibilities we see in mobile networks now let's let's see where these attacks or where
00:03:52
these issues are mobile answers are composed of many many boxes and some of them have been analyzed pretty well by security researchers started from the mobile the radio channel and as a seven
00:04:05
as I mentioned diameter on this side but in the middle of this of this diagram there are plenty of boxes that have not been fully analyzed and especially this one in the middle ims has been covered
00:04:17
by some research but not really deeply analyzed and that's where we are going today not only ims but also RCS as i mentioned at the beginning of the present age okay so this might be new to you so I'm
00:04:30
going to explain why do we have this IMS and RCS technologies mobiles were taught for mobile communications or calls and later for SMS so this was the second and
00:04:42
third generation of of mobiles then later in the fourth generation that the key became the Internet so Internet was added to the mobile and that became the major use of your mobile
00:04:54
so you normally communicate over IP when you use your mobile and in fact between the second generation and third generation and the fourth the difference is that in the fourth the the voice channels that were previously
00:05:07
used just for voice now disappeared so when you make a call over 4G that call goes over IP or has to go over 3G interesting because now many of you are familiar with the IP
00:05:19
technology can look into that and can see if there are any vulnerabilities but not only over IP now we we see a new extension to that so calls over IP where 4G now we extended that to support a
00:05:33
group chat sending files video calling and all the features that you are used to as I said with iMessage or whatsapp or Skype this technology existed for some years but was not really pushed out
00:05:47
until as I said recently by Google this hard push so every mobile from Google so Android will have this technology from Android 9 I think it is going to be deployed so actually most of you already
00:06:02
have it on your phone and you don't even notice you have it we will see what happens later when we try to use messages and so what what are the
00:06:13
possible issues with that and you might ask ok but you are talking about the technology that we don't know so how popular is that technology we try to measure that we took some a list of
00:06:25
mobile operators provided by the GSMA the association of all mobile operators about 900 networks and we try to see how many of them deployed for G so LTE about one-third of them do
00:06:38
and as I said when you have 4G the only way to carry calls over 4G is to do it over IP so there are two possibilities for for carrying calls of over IP one is directly on LTE and the other is over
00:06:52
Wi-Fi so we we measured this via DNS queries we abuse let's say the structure the the particularly structured way of indexing the the nodes in the telco
00:07:06
Network and with this survey we evaluated about 200 deployments support this technology vaulty and 150 support voiceover why fight that is an extension to it now as I said at the beginning we
00:07:20
are interested in RCS this is an extension to everything and we try to measure this and our numbers are about 100 networks worldwide support this technology already but consider these
00:07:32
numbers are lower bound numbers because we can not really estimate in each country how many networks to support RCS because they block the D access to their DNS server but anyway so consider about
00:07:45
100 networks and you want to say ok let's wear so here is the map as you can see most developed countries have this technology already the color on the map
00:07:59
meaning at least one network in that country has RCS on in some countries most of the operators have it for example in the US all operators support RCS already in Europe there are also big
00:08:12
groups like orange Vodafone that's already supported and some countries are currently running trials so this technology is really being pushed out ok this was the intro to the technology to
00:08:25
see what is the coverage of this technology now we jump into our results well we as I said we hope that this technology would solve several problems
00:08:36
but did it did it solve the problems no every category that we listed before those five areas of attacks we found for each of them at least one attack vector
00:08:49
that worked I have to say not all networks are vulnerable to the same vulnerabilities but at least one network is vulnerable to what we say today and we will see there is one particular attack on the
00:09:01
intersect side that applies to basically all networks we could not measure it but we we think it applies out to all networks so what could we do yeah tracking users impersonation fraud and
00:09:14
finally intercept calls I have to say also the first four of these attacks do not require additional information to be carried on so if I want to do call
00:09:27
impersonation so if I want to call a person spoofing the caller ID I don't need any particular new information I can just connect to the network spoof the caller ID and it works well for the
00:09:39
last last attack category we need something more so to intercept cause we need either a configuration file that is deployed on the mobile of our waiting or we need to set up a special man in the middle
00:09:52
attack with some DNS and domain crafter II okay so I will now leave the stage to Cena that will explain in detail all of these attacks and then come back with
00:10:04
the mitigations with user tracking we could find different attack vectors to track users by abusing RCS functionalities the first the fact is
00:10:20
that both RCS and IMS uses C protocol as their signaling protocol and there's a feature in that protocol that party can see if other users available or not that
00:10:33
can happen by sending a sip option packets and if the user is available the response to that request would be a sip 200 okay otherwise network will reply to your request and says user not found so
00:10:46
what the attacker can do here is to prepare a list of numbers that he wants to enumerate send sip options packet to the RC score for each of those numbers and collect the responses if the user is
00:11:00
available attacker will rip will receive as two okay including some information about user since all operators have interconnect for IC RCS and IMS this
00:11:14
attack can be scaled to international numbers and different operators so the attacker will be able to even enumerate users in different countries and different operators the SIP 200 message
00:11:26
coming back to the attacker would include the user's IP address device model and different information based on that IP address attacker will be able to
00:11:38
roughly locate the location of victim based on the IP geolocation databases especially if that IP address is ipv6 since recently all mobile mobile
00:11:50
operators are moving to ipv6 we have found another attack vectors to find user location I'm gonna elaborate on that later in this presentation but for now let's move on to
00:12:04
impersonation and fraud attack there is a really well-known and old attack in sip protocol that an attacker is able to craft caller ID this happen by in
00:12:17
crafting a sip invite message and changing the caller ID when we were working on this research we didn't expect that all vulnerability still exists in this new technology but
00:12:29
surprisingly we could find different networks vulnerable to this attack vector how'd this happen first the attacker needs to connect to the network by his own credentials through sip register after establishing
00:12:42
the connection he can craft a message a sip invite message and sent to that another party sip invite is used to establish a call or sending a message
00:12:54
and in that message attacker will be able to change the caller ID set any other numbers for example premium numbers or a number which is expensive to be called so he can cause the weak
00:13:08
team to be charged more money or attacker would be able to earn money by making a Mis ko changing the IP changing the ready to a premium number owned by the
00:13:20
attacker so if the victim is curious enough he would call back and attacker would be able to earn money by receiving that call besides of that these traditional and old vulnerability in sip
00:13:34
we could find a new attack vectors in RCS the fact is that some RCS course can't recognize their users only based on the public IP address and the
00:13:47
username username is usually is the phone number of the user so if the attacker and the victim both uses the same public IP address could be through
00:13:59
the VPN connections or Wi-Fi NAT the RCS core would be would not be able to recognize if the request is coming from the legit user or an attacker or someone
00:14:11
else in that case an attacker will be able to craft sip messages sent to the RCS core since they have attacker and victim are using the same public IP address
00:14:24
RCS core cannot recognize if that's the legit request or not and will accept the connection so let's go through that this attack by watching a video here we have
00:14:40
a hotspot ran by attacker and we monitor our victim and week two friends devices to see messages between them okay
00:14:52
attacker which team looks for probably free internet connection connects to the hotspot ran by attacker and immediately after connecting to the internet our sis
00:15:04
client tries to connect to the RCS core by retrieving first p-cscf connection IP address and then establishing the connection okay as we see here
00:15:16
connection goes over TLS unfortunately we cannot intercept that we cannot see what's going on but here we can see to which p-cscf the client is connected and
00:15:28
what port number okay next step finding the IP address and port number here we have it and we
00:15:39
also developed a tool that receive sender phone number receiver phone number also it needs the p-cscf IP address and port number and we could set
00:15:53
an arbitrary message that will be sent to the another party so our tool can actually craft a sip invite and send it to the RCS core and as we see here since
00:16:08
attacker and victim both are using the same public IP address our Cisco couldn't recognize that packet is coming from an attacker and is that a legit request so our z-score accepted our
00:16:21
request and delivered the message to another party without even notifying the real user that you are sending something okay
00:16:31
let's move on we saw fraud impersonation and one attack vector for tracking user but we also explore different
00:16:47
functionalities in Arceus there is another functionality in our CSS as Luke already mentioned to transfer media files like whatsapp iMessage and other messenger applications that you can send
00:17:00
Widow picture video for video calls and stuff like that and the way this feature work in RCS is that the RCS client first uploads that file for example image to a
00:17:14
file transfer server the FD server replies with an XML confirmation including two different URLs in that XML XML confirmation one is thumbnail URL
00:17:26
and the second URL points to the actual file uploaded to the FD server RCS client sends that XML confirmation to the receiver and once the receiver gets
00:17:37
that XML data the RCS client automatically starts downloading the thumb URL without asking the user so here in this case an attacker will be able to
00:17:51
just craft an XML confirmation put the URL of the thumbnail pointing to a large file hosted on a target website and send that XML confirmation to a large number
00:18:04
of users once those users receives that XML confirmation RCS client automatically without asking the user tries to download the thumbnail and it
00:18:17
can cause a DDoS attack against of that target website also the thumbnail URL can point to a server under control of the attacker so once the receiver gets
00:18:29
that XML confirmation data tries to again make an HTTP request to that server and reveal some information about the victim such as IP address such as
00:18:40
device model that can make attacker able to track the user location also what we found super interesting we found some specific implementation of
00:18:54
RCS client that attacks really really in from sensitive information to the HTTP requests those specific clients attach a session token as HTTP header to the HTTP
00:19:08
request to the thumbnail URL and tries to download the file so if attacker crafts the URL and have his own server attacker will be able to collect session
00:19:20
tokens and session token makes the attacker able to take over the victims account completely ok let's explore
00:19:32
other attack vectors here the more interesting one interception we could find three different attack scenarios to intercept text messages through RCS the
00:19:44
first one is while you're abusing X cap weaknesses X cap is an interface that in RCS which is used to set call forwarding we could set
00:19:58
for ratings for a week team and receives the week team's calls the same as what we could do with ss7 protocol I'm not I'm not going to elaborate on this attack scenario in this presentation but
00:20:10
we are going to focus more on the last two scenarios the second scenario is to abuse Arceus provisioning security issues we could find four different ways
00:20:22
for abusing the RCS provisioning and the last one will be to do a DNS spoofing and doing a sheep man in the middle attack let's start with our C's
00:20:35
provisioning let's first see what ours is provisioning is and how it works provisioning means to configure the credentials on the user's device so the device would be able to connect to the
00:20:47
network the way it works in RCS is that our sis client first makes an HTTP request to the config server in case you in case the user is using LTE connection
00:21:00
the config server will use HTTP header enrichment and authenticate user based on his connection then config server replied in that case OTP verification
00:21:14
might not be necessarily by operator so the config server replies a session ID and if a connection is over the Wi-Fi also config server sends an OTP through
00:21:26
a binary SMS once the user has both OTP and session ID it will make another HTTP request the config server including OTP and session ID if all received
00:21:40
information by config server is correct the config server replies an XML file XML provisioning file including credentials and different parameters that client needs to use in order to
00:21:54
connect the artsy's so first ever attack scenario that we came up with was to having a malicious application on the target phone in case there's a malicious application residing on your Android
00:22:08
phone it will be able to do the provisioning process by abusing your LT connection to the network retrieves the config file and upload it to a server under control of the
00:22:20
attacker it might be a question there might be a question okay what if we cannot make our victim to install the malicious application it's not the case always the second attack scenario that
00:22:34
we came up with was to abusing the internet connection shared through a hotspots imagine the weak team is sharing internet connection with an attacker an
00:22:46
attacker can make requests to the Internet through the victims LTE connection so attacker will be able to do the provisioning process again
00:22:57
receive the session ID first and then config file and abuse the config file as we see later how it would happen again there might be a question okay it's not
00:23:10
always the case that we can tamper the user to share the internet connection or maybe installing a malicious app we also surprisingly found that some is another
00:23:24
way that we can use a fake access point in this case victims connect to the attacker access point malsu's JavaScript payload will be injected to the user's
00:23:37
browser and that JavaScript code will help attacker to retrieve the config file it might sound a bit complicated so let's go through this attack by watching a video demo
00:23:55
okay here on the right side we see the week team's phone looking for free internet connection and a hotspot ran by attacker okay
00:24:07
our victim is looking for Internet and in few second finds their free hotspot and connecting to the attackers hotspot after connecting to the hotspot user
00:24:24
starts browsing the Internet opening a website or whatever and there we go ethic is done it happened quickly so
00:24:36
maybe you didn't realize what happened victim connected to the rug access spot hot spot and it started browsing the internet the fake access point fetched
00:24:50
the actual content that user were looking for injected malicious JavaScript payload into that and returned back to the users immediately after that disconnected the user from
00:25:01
the hot spot so the phone falls back to the LTE connection but the JavaScript payload is still running on the browser's engine so the and also what
00:25:15
you can see here on the victims device the URL change to a 3gpp network URL because we need to use the same context for that that JavaScript fetch the
00:25:27
session ID through the LTE connection and sends that session ID to the attacker server so on the attacker server he will be able to retrieve the actual config file now we have a config
00:25:39
file on our server I guess I reload sorry okay now we have a config file on our server let's take a look and see what we
00:26:01
can find in this config file here here on top we see a token value which is masked because it's a really critical value in this config file by using that
00:26:14
token value attacker will be able to retrieve the config file later without need to do OTP verification without need any access just by using that token value also we
00:26:27
see the victim's phone number here other parameters let just a school down here in the file okay
00:26:39
here we see a set of credentials here which is used to connect to the RCS core by client once the attacker has these credentials he will be able to do whatever on behalf of the victim that
00:26:53
means completely I can't take over also there is another set of credentials here which can be used to upload media files to the file transfer server also there
00:27:08
are other parameters here for provisioning that client needs to have but they aren't really interesting values for us so coming back to our presentation okay all of those attacks
00:27:23
might need tempering the week theme but there might be some possibility to do a fully remote attack in case even OTP verification is needed we surprisingly
00:27:37
found some some networks vulnerable to OTP brute-force vulnerability this attack can happen in two steps at the first step attacker would need to
00:27:50
enumerate what it aims is by sending HTTP requests to the config server and config server returns different values and HTTP status code based on the validity of MZ as we can see here on the
00:28:03
top right a screen shot as it config server returned 200 okay for valid and for all three four invalid MCS once
00:28:14
the attacker have valid MCS he can try to brute-force OTP and if the network doesn't apply rate limiting for OTP verification attacker will be able to
00:28:26
retrieve the XML config file by brute forcing the OTP as you can see on another a screenshot that we could retrieve the config file by brute forcing those OTP okay we saw four
00:28:41
different ways how to abuse our seas for visioning and retrieve the config file now we have the credentials and it's time to do message interception the way intercepting works is that the user is
00:28:55
connected to the network either by LT legacy networks or RCS doesn't matter the attacker on the other hand on the other side uses the credentials that
00:29:07
retrieved to connect to the RCS core while the attacker is try is connecting to the RC score he makes sure that he sets SMS or SMS over IP value true SMS over
00:29:21
IP tells the RCS Network that this instance is able to receive SMS messages over IP protocol after connecting to the our z score attacker will wait for
00:29:32
receiving an SMS how it works once someone wants to send you an SMS for example your bank wants to send you an OTP the SMS delivers to the SMSC SMS he
00:29:46
asked your home network where that message should go since there is an instance available that can receive SMS over IP this message will be forwarded to i PS M gateway in that note the SMS
00:30:00
packet will be converted to the IP packet and will be delivered to the attacker first via SIP message once the attacker receives this message he can decide to acknowledge the message or not
00:30:14
if the attacker acknowledged the message the the the network doesn't deliver the message to the actual user otherwise the message will be delivered to the real users too we were thinking
00:30:26
of okay how we can abuse the security issue the first scenario that came to our mind was abusing the Google password recovery for Gmail and receive an OTP by
00:30:39
exploiting this vulnerability let me show you how we exploit that vulnerability to take over gmail accounts okay here again we see our
00:30:52
victims device which is not related really to these attacks but we see the attackers laptop - okay attacker starts
00:31:06
the password recovery process by just selecting the gmail account definitely we don't know what password is and we ask Google to send us a text message we
00:31:19
have developed a tool here that uses a victim's config file connects to the Arceus message set SMS / IP flag true and waits for incoming sip messages
00:31:31
after connecting to the rcs core we can ask Google ok please send us an OTP for verifying our identity and we see after few seconds that we can receive the
00:31:43
message even before the actual user there we go we have the OTP here and since we don't acknowledge the message it will be also delivered to the actual user after few seconds we just want it
00:31:59
to monitor the victims device to see that we are intercepting the correct OTP and message by having this OTP we could just proceed with the password recovery
00:32:11
process set a new password for that target gmail account as we see here and completely taken over the that Gmail
00:32:21
accounts yep there we go thank you okay we also investigated more
00:32:40
in RCS and also Android default messenger and we found another interesting attack vector that comes from a wrong way of validating TLS
00:32:53
certificates what happens once the client have the RCS config it tries to find the IP address of p-cscf by querying the dns and after having the
00:33:08
right address tries to establish a TLS connection the only thing that RCS client actually the Android default messenger does is to verify if that TLS
00:33:21
certificate is valid or not the client doesn't check if the certificate matched the domain based on the config file so what an attacker is able to do here is
00:33:33
to do a dns spoofing sends a fake answer to the srv4 p-cscf and set a domain under his own control pointing to a
00:33:45
server under his own control - and this next step the client tries to connect to that fake p-cscf and the attacker replies to that TLS handshaking with a
00:33:59
valid certificate so the client trusts the connection and starts sending the sip messages on the other side the fake p-cscf under control of the attacker is connected to the legit p-cscf so
00:34:13
attacker will be able to do a man-in-the-middle attack on sip messages he will be able to seize all sip messages going on and even he will be able to modify packages we also worked
00:34:27
on this issue more we could develop some tool to exploit this vulnerability that I can show you why our demo here okay here again we see two Android
00:34:47
devices one our victim victims friend and a fake p-cscf is a sip proxy running on that on the attacker server the victim tries to connect a hotspot ran by
00:35:00
attacker and okay yeah after connecting to the hotspot again tries to find the p-cscf and connects to
00:35:17
the rcs yeah here we see in response to the SR we request to the SIP stat tcp we
00:35:34
replied with a domain under uncontrolled p-cscf that s our labs that de the client accepts that response and tries to establish TLS connection since
00:35:47
replied with a valid certificate issued to that domain again to a client trust that our certificate and it started negotiating the sip messages as we see here we got sip register and we did a
00:36:01
transparent proxy between the alleged p-cscf and the client then in this case victims wanted to reply to an existing
00:36:11
message so our tool will be able to detect paypal addresses and replace it with a fake one so as we see here we
00:36:28
could catch a sip invite message including a PayPal Handler and replace that with our own PayPal Handler and deliver the modified message to the weak
00:36:40
to the victim's friend and all connection went over the TLS and without notifying anyone that something is going on in the middle okay let's get back into the next step
00:37:00
so I don't know if this was surprising to you but basically we found a bunch of vulnerabilities that we did not expect to still find in modern systems so all
00:37:12
related to HTTP misconfigurations sip also miss configuration or bad implementations and all of these carry on this pretty critical attacks so what
00:37:24
can we do about it we we listed here seven best practices that should be taken by mobile operators and vendors in order to fix those issues and I will
00:37:38
start by protecting those the configuration file that Cena could retrieve pretty easily in four different ways so how do you protect the provisioning the standard specifies a more secure way of authenticating
00:37:51
clients so this is the one that we recommend using the SIM card as a secure element to authenticate the user it's called GBA if the network for any reason does not support that feature
00:38:04
because the vendor does not support it there is of course the option to turn on OTP and we saw that some networks don't do OTP currently so definitely turn on OTP and make sure that your OTP is a
00:38:17
pretty strong OTP so let's say eight characters alphanumeric and then in conjunction with those measures make sure that you apply rate-limiting on those requests so whenever you have a
00:38:29
possibility to brute-force something make sure that you slow down the attacker for example allowing only three attempts for the OTP or saying this OTP is only valid for five minutes and that way it should be very hard to brute force it
00:38:42
this was to protect the RCS configuration file but there are also some issues that are affecting that the network size for the actual core for that there are other three measures we
00:38:55
want to validate the client identity we saw that the network was only identifying clients by the external IP this is not possible there should be some other more strict way to do that example using the four tuples or source
00:39:08
IP source port destination IP and port and maybe also the socket ID to verify that the client is connected and after the the identity is verified no other client can connect and spoof the same
00:39:20
identity we saw that there were some information that were leaked in these messages there is clearly some way to protect against this attack so the SBC that is the border gateway of the
00:39:33
network should mask all these values that come from the users towards us other users so for example the IP or the the model or some other information that a client are sending to the network and
00:39:46
finally the file uploads we saw that because you could specify a foreign domain you could trigger a client to download something from a external source well the standard says that that
00:39:59
domain should follow a specific pattern and these clients did not implement that check so make sure that the the files that are sure when you between users match that specific domain so no Xcel
00:40:11
domains can be used and also try to validate the content type and size of the file before you deliver the XML on the other side and then the very last issue we we presented that's a
00:40:23
combination of well certificate validation and and DNS mistrust we cannot fix the DNS because we know today we cannot do that but we can enforce that the domain specified in the
00:40:36
configuration file has to match the one in the certificate from the server and this can be done and this involves some of some some to-do list for the for the vendor so for Google and for the
00:40:49
operators we we are in contact with with both we communicated this issue and they are currently working on it okay these are the best practices that should be
00:41:00
adopted by mobile operators and vendors and if everyone does its job correctly we will have actually a secure RCS a new SiC new technology that is actually
00:41:12
secured ok so closing the presentation our security researchers we are always interested in new technologies we we were surprised by all the issues we found in this technology
00:41:25
and actually there is probably a reason behind it the reason is that it's all over IP right so everyone now can have a look into these protocols and find vulnerabilities and the other thing that
00:41:38
I think is behind this issue is that there are new vendors that came into the market because it's very easy to to create a web application let's say so many new vendors came into the market
00:41:50
and those vendors are probably not having that experience with security like the old ones and that means well they introduce new vulnerabilities so I will encourage all the security research community to investigate every new
00:42:04
technology that comes out and let's fix it before it's too late in this case it's currently too late this technology has been deployed and it's already broken so well I know that mobile
00:42:16
operators and and Google are really working hard to fix this maybe today even it's already fixed I am not sure about that but definitely let's keep keep testing keep keep pushing the security best practices
00:42:30
around and just a final note I want to thank all the security he research labs team that work on this and not only I and Sina work on this so also Lukas Euler and Martin's are thank you very much and thank you all for for listening
00:42:43
to to our talk any questions thank you for a great talk and if you don't have an an application
00:43:12
that can read the sms's is the only way to get the OTP from the binary SMS to brute-force it so you're asking about when a network uses OTP and forces OTP
00:43:23
for the client provisioning I think so okay so one option will be to to have malware on your phone that has the permission to read SMS then it will be clear the other way would be to
00:43:34
brute-force it but as I said that that's possible in some networks because they don't implement rate limiting but if you do it correctly it's not possible approximately how many networks implemented rate limiting I can say
00:43:49
rather the other case so we found two networks where this was possible the the length of the OTP was five and six digits and the ID was not well protected do they all enforce al GP authentication
00:44:01
and no so probably if you have seen the other scenarios where we we can capture the FCS config without any OTP so with the rogue hotspot in the middle for example thank you
00:44:25
so for one of the attacks you say that you need to brute force the IMC hmm so I'm see sixty bits so how long it takes no the MC is 15 digits and the first five are defined by the mobile operator
00:44:38
and there are other ten yeah so you can just randomly generate ten digits and there is a very high chance that you will find one that works because there are millions of users in the network so it's pretty easy to find one that works
00:44:51
it might not be the one of your victim that's pretty hard of course but right so how do you correlate like your your victim right so there are plenty of other attacks like MZ caches for example
00:45:03
there is one attack that I didn't mention today that involves also IMS and RCS technology whenever your mobile connects to a hotspot the mobile tries to connect to this voice over Wi-Fi
00:45:15
technology the epd G and when doing so it discloses the MZ so I could be sure of your MZ by doing that for it so I have a next question so do you think these attacks will be applicable to 5g yes
00:45:28
so RCS is an IMS are technologies that are carrying voice over IP and they apply to 4G and 5g so so in fact you actually I am Z is not exposing their attacks so in that case what will be et
00:45:42
so this is the theory 5g will introduce encrypted in Z's whenever networks do standalone deployments but so far the 5g networks that I've seen in the world are not standalone that means your Eames is
00:45:56
still going unencrypted and because of legacy your mobile will still be able to send the unencrypted MZ back to the network so on 5g not but if you can force the user to connect to 4G 3G or 2g
00:46:09
you can still capture the MZ thank you for this very interesting talk on slide 14 when you transmit the in
00:46:32
step 3 the XML file yes after delivering the file will the content be executed or displayed or is it just yeah passively it's of course a good question
00:46:47
there is XML and there are plenty of attacks around XML I think we tried some of them but we couldn't see any any issue with that so the only issue was the logical issue of the URL not being
00:46:59
trustworthy yeah it depends on the library I have to say so if it's Java there is a low chance that something goes wrong but if it's C well okay so thank you again and make sure
00:47:24
you update your phone soon thank you
End of transcript