 Apparently, it's becoming a tradition that every year at Congress we have at least one talk that gives you nightmares about your cell phone. I think this year it's going to be this one, so please welcome our speakers, Dongkwan and Honggil. Good evening. I'm Honggil Kim from South Korea, that does. So please, please don't ask about our registrar or us. I only know what to know about it. And this is my first time attending Z3, and it's a great pleasure to present our work for this time. And today my colleague Dongkwan and I will talk about dissecting both various vulnerabilities in a new voice technology and LTE networks, and we will show you how to exploit and fix these vulnerabilities in operational LTE networks. So we both are graduate students in the system security lab in KAIST. So my main research interests are cellular network systems, mobile device security, and internal things. So I'm currently working on the security impact on LTE core components against those attacks. I'm Dongkwan Kim, hi, and I'm interested in several fields of security issues. And today in this talk, Honggil will describe the basic concepts, and I will explain the details in the later part. So let's start. Okay, so both which stands for voice over LTE is a new voice technology and LTE network. So in case of traditional 2G and 3G networks, the delivery network for voice and data are separated. However, in LTE, it is implemented into the all IP based network to provide a faster data delivery. Thus both the voice and data in LTE are delivered as a data flow. So for voice implementation, LTE has to replace the previous 3G core solution. So for this, LTE adopted for your IP system, which is widely used in our network. So by adopting both, for LTE users, they can get high voice quality, a faster set of time, and they can save device battery life. And also for operators, they can increase usability, and they can reduce operational costs, and they can also provide rich multimedia services that have not been provided in 3G cores. So let's see more detail about the 3G and 4G networks to understand how the voice technology is changed. In case of 3G, the delivery network for voice and data is separated into two parts, the packet switching and the circuit switching. So the data is delivered by the packet switching core, and the voice is delivered by the packet switching core. So when a 3G user makes a 3G call, then the signal goes to the telephone network through the circuit switching core. On the other hand, in LTE, both the voice and data is implemented into the packet switching core. Therefore, it no longer utilizes the circuit switching core for your IP server implementation. Most of server functionality is implemented inside an IMS, which is sent for IP multimedia subsystem. So let's see more details about how the services are delivered in LTE. So in LTE core, all server services such as data, video, and streaming are delivered as data channels, which is called barriers. The barrier is a virtual connection between the device and the core network to support the specific QoS of each service. As you can see here, 3GPP standards specify several barriers based on the QCI value from one to nine. Depending on the purpose of the service usage, each barrier has different characteristics such as guaranteed or non-guaranteed bid rate, and priority, packet delay, and packet loss rate. So as you can see, there are two barriers for both, and both of them have the highest priority and the lowest packet delay and lowest packet loss rate for barrier performance. So back to the service delivery concept. When a device turned on a certain service, the default barrier between the device and the core network is established with assigned a new IP address. So generally, this default barrier support does not guarantee the bid rate, but it supports best for delivery. So when the service requires a specific QoS, then the dedicated barrier is established within a default barrier. And generally, this dedicated barrier shares the same IP address with the default barrier. Instead, the traffic through this dedicated barrier is filtered by the protocol or code number. So in specific default, two barriers are needed. So one is used for control plane, and the other one is used for data plane. So when a user turns on a fault service, default barrier is established between the device and the core network. And through this default barrier, a device first authenticates itself to the IMS by sending the SIP signaling messages. And after that, when a user makes a call or gets an incoming call, then a dedicated barrier is established within a default barrier. And through this dedicated barrier, the voice data between the caller and caller is transmitted, and it is usually encapsulated into the RTP packet. So since fault is a totally new feature compared to the traditional 3D calls, adapting fault makes a whole satellite infrastructure more complex. It involves not only the implementation of the LTE core, but also device mobile-based support, device hardware interface, and even accounting functions. So if some of these implementations are not carefully considered, it may cause a severe security problems. So we decided to check potential attack factors newly introduced in Vault. And guess what? We found several security issues in each component. Thank you. And these security issues are mainly caused from the two facts in Vault. One is the fault accounting and the voice solution in LTE devices. So I explained the fault accounting first. In case of 3G, the accounting is depending on how the service is delivered in the core network. So since the data is delivered by the packet switching core, it is charged by the byte usage. And voice is charged by the time usage of channel allocation time for calling. So similarly in LTE, as LTE has only the packet switching core, both the voice and data is delivered by the packet switching core. So it's natural to apply the bi-usage for all services. However, most operators still separate the accounting policy for both voice and data. Therefore in LTE, most operators still apply the time usage accounting policy for Vault, even though the Vault is delivered by the packet switching core. So this kind of implementation may cause a very complicated accounting function of LTE. So from this, we might ask, do operators implement this complicated accounting correctly? And for second problem, we need to know the anatomy of smartphones. So generally, smartphone has two processors. One is application processor for running mobile OS such as Android iOS and running user applications on top of OS. And the second one is the communication processor and it is used for modern functionality and hardware specific jobs such as handling digital signal processing. So before explaining the device solution in LTE capable devices, I explained the 3G device solution first for comparison. In case of 3G devices, the voice call signaling procedure is done by hardware in CP. And also most information about the CP's implementation is hidden from the manufacturers such as Samsung, Qualcomm and Huawei. Or even a malicious app which has routed an IP part cannot easily access to the CP part to manipulate the call signaling procedure. Also any app in AP have to use the specified call APIs with a call from permission to make a 3G call. That means that an attacker in 3G phones cannot easily analyze the call signaling and voice implementation in both device and the call network. However in LTE devices, the voice signaling procedure is done by software in AP. Which means a user app can easily access the voice call signaling procedure by utilizing the network's OK for both. So for example in Android system, there are two network interfaces, R&D 0 and R&D 1. And by simply checking the running applications and listening port, we can infer that R&D 0 interface is used for both services since 5060 is a default port for SIP signaling. And also from this, we thought that an app can even make a call without a call from permission. It just needs an internet permission to utilize the network's OK for both. So we have two findings involved. First one is the complex accounting infrastructure. And the second one is delegating voice signaling procedure to AP. So to exploit these facts in operational alternatives, we first analyzed 3GPP standards related with the voice service. However, these standards leave detailed implementations to the entities who have to implement it, such as operators, chiefs, offenders, and so on. So we decided to make a checklist of potential vulnerable points in the voice feature. And it was about 60 items for both control and data plane, like this. And with this, we performed an empirical analysis in five major operational alternatives. This includes two US operators and 3,000 Korean operators. And at this time, we also considered the operators in Europe. However, at the early 2015, the operators in Europe does not provide voice service. But now I heard that some operators in Germany started to launch a voice service. So if you are wondering how secure the German operators' voice service is, then please contact us and let's look into it together with your smartphones. So in summary, this is the summary of our results. We found four free data channels which are mainly caused from the complicated accounting function. And five security issues. So for each issue, my colleague Dong-Kwan will explain that. Hi again, I'm Dong-Kwan Kim. And so let me take over from this part. And so let's start from the free data channels using world protocol first. To utilize such free data channels, first we need to understand how actually work works. So when caller makes a call to callee, caller sends an invite message like this. And this invite message contains the phone numbers of caller and callee. And it is just look like this. You know, to keep my privacy, I removed some of my private information. But as you noticed, this packet is just like HTTP. And the methods section for get or post is changed to invite like this. And, you know, there are many methods in SIP messages here, like here, and also phone numbers of caller and callee are here. So when caller receives this invite message, then the phone starts to ring. And when the user answered the phone by touching the call button, then the callee's phone sends an OK message to the caller. And the dedicated barrier for voice data transmission is established between them. And voice data is transferred through this channel as RTP packets. So how can you utilize this for free data channels? It's really simple. You can just put data into the head or body of the invite message. And note that we replaced the OK message to decline message to receive invite messages over and over. Also, you can think of put data into the RTP payload like this, just like normal voice data. And we actually implemented both tunneling methods. But some of you might think that the concept is too simple, but the actual implementation was not. So let me explain the details. The left part is a caller's phone, and the right part is a callee's phone. So we actually implemented, there are two senders and receivers for each tunneling method. And when caller starts to send data, SIP or RTP packets are transferred through IMS. And SI packets are received in AP in the callee's part, but RTP packets are not. This is because this is the difficult part. So because the RTP packets are firstly processed in CP, and only audio data is passed to AP, which means you cannot get the RTP packets in AP with TCP dump. So furthermore, this audio data, the size of this audio data is too small, so we cannot utilize the full bandwidth. So we need to find another way. While searching, while googling, we found there is a diet command. And so what's diet command? Actually, diet is a proprietary protocol by Qualcomm and also introduced by Delugra at 20CCC. And diet command provides several functionalities, such as memory read write or SMS read write or signaling dump. And the signaling dump is one of the main functionalities of diet, because you can dump any signals between your phone and the cell tower. So this is usually used by the operators for performance tests, so-called field tests. You can see the right figure, and that's one example of diagnostic protocol tool. And the software is on the laptop. And to utilize that software, you need a key stored in the USB. And can you imagine the price of this software? It's really expensive. It's over $16,000. So because we are students, we don't have enough money, so we cannot buy that one. So we need to reverse engineer the diet protocol itself. And we found several operational codes as left table. And actually, we found 100 commands, but we only put a part of them here. And there is a load command here. So by using that load command, we could directly catch RTP packets in AP through DIAC device driver in the Linux corner. You can just open the DIAC device driver and send that command. Then you can read RTP packets directly. So we can get the SI packets and RTP packets without any loss. So we can utilize both tunneling methods with this. In case of direct communication, it is much simple. You can just open a socket with the IP address for a vault interface and send data to the internet like this, or others IP addresses for a vault interface like this. You can also think of not only free data channels, you can also think of overlaying other people. So utilize your vault interface, send data to the other data interface like this. But actually, we didn't test this. And another team who are also working on the VoLT, they tested this. But we didn't actually test it this. So maybe you can try this one. So we tested free data channels for five operators, two in the US and three in South Korea. And note that the implementation was different depending on the operator's policy. So SIP tunneling and media tunneling were available for all the operators. And direct communication was somewhat different depending on operator's policy. And note that the KR-1 is the best operator that you can utilize for free data channels. So I guess some of you might wonder using KR-1 later if you travel to Korea. But actually, after we reported this vulnerability to the operators, they were patched like this. So don't be disappointed. And we didn't get any follow-ups from the two US operators. Because we are Korean students, we couldn't actually test those again in the US because it takes too much money for us. So later, if we have some chances, we can test later. We measured the throughput for the direct communication. And it was quite high. And as Hongil described in the previous slides, our vault interface has higher priority than normal data interface. So it is more useful. Thanks. And we also measured the throughput for the media tunneling. But it was quite small because it is limited by the operators. The operators are limiting the bandwidth for media tunneling because they think it's enough to provide high-quality voice service. But later, if they allow more bandwidth, because we can fully utilize bandwidth, I think the performance will be increased, too. And in case of SIP tunneling, we didn't actually measure the performance because it can cause a severe problem to the core network, which means a denial of service will take on the core network. So I will explain this in the later slides. But actually, when we tested on one Korean operator, I sent about 1,000 invite messages within a second. And two or three hours later, we got a call from that operator. So we got in trouble. But it worked out well. We discussed and we patched together. So it was OK. So I introduced four free data centers. And now I will explain the five security issues. First of all, all your voice packets are not encrypted. So only one US operator was encrypting your voice signaling packets. And even in that operator, the voice data was not encrypted, which means all your voice data can be wire tapped. In that US operator, they are using IPsec to encrypt the voice signaling packets like this. I removed the IP addresses for that operator. And the other operators were just using TCP or UDP without encryption. So your voice data is free. So some of you might wonder if wire tapping is really possible. But one example is this. You can think of phantom cells. There are a lot of phantom cells worldwide. And almost all operators are providing phantom cells. And if this phantom cell is compromised, all funds connected to that phantom cell can be affected by this vulnerability. And even more, some operators are providing Wi-Fi calling. And if you utilize this Wi-Fi calling, all your voice packets are transferred through wireless AP through the internet to the core network. And compromising wireless access point is much easier than compromising phantom cell. So in this scenario, all your voice data is also wire tapped. So come back to the first slide. Even though in this situation, the operators are only focusing on encrypting the voice signaling packets, not the voice data. So we suggest that the operators should also focus on encrypting the voice data. The next problem is that even though the SIP servers in IMS should authenticate users and manage the call sessions correctly, there was no authentication and no session management. So you can make a call with fake phone number where you can send multiple invite messages at the same time to several users, then several call sessions can be established. In a normal call, only one user can call to only one person. But because of this vulnerability, you can call to anyone at the same time. So one sender can deploy lots of better resources in the core network. So compared to previous denial of service attacks on the core network, we only need a small number of devices to kill the core network. So that's the reason why the operator called us. Actually, we prepared a demo for the caller spoofing. So this is normal call. When caller calls to cally, then the attacker calls to cally using the caller's phone number. So let's see the demo. The right part is normal caller and cally. And we use our photo. This is Hong Il and this is me. This is just normal call. And they communicate and hang up the phone call. Now the attacker is connected with ADB just for convenience. And we uploaded the call to the attacker's phone and call to cally using caller's phone number. So the call is from the attacker to the cally. And caller didn't know even his phone number is used. And in this demo, we utilize a famous Korean song, Gangnam style, but actually we can send any audio data. So we can change the phone number and send any audio data. So this can be used for voice phishing. Or for example, you can earn some money from your friend by using this vulnerability. And next problem is that as I mentioned before, there is no rule at the gateways. So in a normal situation, all voice packets should pass through IMS. But we found that we can directly send those packets to other phone. So there is no authentication and no session management again, so caller's phishing again. Another interesting problem is that there is a problem on the Android system. So previously, all applications should have call phone permission to make a call. But as Volt is newly adopted, the call procedure is moved from CP to AP. So there was a problem on the Android permission model system. So we can make a call only with the internet permission. The internet permission is a very basic permission. And almost all application installed on your phone has that permission. So almost all apps can perform this kind of attacks. So they can blog your calls or make an expensive video calls to the others to give you expensive bills. And we also prepared demos for the dinner service on calls. So note that the malicious application is running in the background of the victim's phone. And it does not leave any trace so the victim cannot recognize if he is calling. So the app makes a call to the attacker and it blocks the caller's normal call. And when they are on the phone in a normal case, the app can cut off this call. So let's see the demo. This is call blocking demo. See the background app calls to the attacker. This is the lioness business message in Korean. So you can block any call. And this is cut off demo. They are on the phone. This is normal call. And malicious app on the victim's phone can cut off this call by calling to the attacker. So the app only with the internal permission can completely block victims from calling. To summarize, we found these kind of vulnerabilities and four free data channels. And we also suggest several mitigations for them. So because they are not encrypting the voice packets, they should encrypt those voice packets. For example, they can encrypt voice signaling packets with IP seg or TLS. Or they can encrypt the voice data with SRDP. And the problem of authentication comes from the operators because they only authenticate users with the SIP header. Which means because SIP packets are just application layer protocol, so anyone can manipulate those packets. So we suggest to prevent such vulnerabilities. As I mentioned before, every vault interface has its own IP address. So the coordinator can recognize the origin of the packet. So they can check the source IP address as well as the SIP headers like this. And proper session management, and they should set up proper rules at the gateways. And to prevent permission on their mismatch problem, mobile OS developers should strictly bind the sockets to the data interface, not to use the vault interface. The problem in the Android system is that if an application opens a socket and you set the destination IP address to the SIP server in the IMS, then the Android system automatically routes packets through the vault interface. So that was the problem. And actually, we reported to Google and they patched like this in the early of this November. So they set up some capability flag for IMS. And they check that if an application without system permission makes a call, then they block that application. So it is patched. And to prevent SIP and media tolling, you can perform deep packet inspection. But media tolling is not easy to reserve because you can encode your data just like voice data and put that into RTP payload. So it's not easy to solve. Byte usage or counting might be one solution. But I think the operators will not follow this because they are very sensitive to their profit. And currently, they are using time-based accounting because it's much more expensive than the byte usage accounting. So it depends on the operator's policy, what to choose. And while doing this research, we found that the 3GPP specifications has problem. So the specification was too abstract. And they left the details to the operators. So the operators misunderstood and misimplemented the details. And also, the important security features in the specifications were just recommendation and not requirements. So the operators not follow those security features. They reported these vulnerabilities to US and KR certs and Google in May. And Google replied, moderate. And all two US operators were just act and we didn't get any follow-ups. And only two among three Korean operators were patching with us. And one Korean operator even didn't give us back act. So we don't know about that Korean operator, even though we are Korean. And while doing this, we was quite impressed by the US certs in their way handling the vulnerabilities. They actually set up the vulnerability nodes. And when we sent our report to US certs, they sent our report to all the US operators, as well as Google and Apple. And Apple replied that the iPhone is not vulnerable to this vulnerability. So I guess they are just strictly binding sockets to the data interface. So that's why the iPhone is not vulnerable. And we got a CV list or so. So even though we are young students, even though the level is moderate, it's just third level. But it's a starting point. So we think the problem is still interesting. Thanks. And do you think VUIP system is still secure? Right. Because some people might think that VUIP system is secure enough because the security of VUIP have been studied for several years. But actually, we tested on one VUIP system, and it was vulnerable like this. So we think that if VUIP system is interconnected with VUIP system, then this would be another interesting issue. So to summarize, because of the two findings from the vault interface, we found four free data centers and five security problems. And I think these problems are related to all the parties, such as 3GPP specifications, or telecom companies, and so on. And every new system has vulnerability. And so as vault is newly adopted, we targeted vault to analyze its security. And as more and more systems are adopting cellular technology, before it's wide deployed, holistic re-evaluation of vault should be applied. So thank you for listening. And I will take any question. OK. We have a very large amount of time for Q&A now. So please line up at the microphones. If you feel the sudden urge to leave this room, please either suppress it or leave very quietly because it gets very noisy in here. If lots of people talk and then run away. OK. Microphone number two, please. Hi. This is very interesting. I have a few part question about the spoofing attack. Basically, what you're doing there, you're sending C packets directly to the other phone, right? Right. So the network has no filtering whatsoever, like the first forwarding internet. They have no filtering whatsoever on that. There is no filter. You can just change your phone number to target's phone number, then you can perform the caller spoofing. Have you tried spoofing also your IP address on that interface? Is that possible? You mean IP spoofing? Yes. No, we didn't try IP spoofing. But when we tested it on a few months ago on the Korean operators and US operators were not vulnerable to IP spoofing attacks. Thank you. Oh, just another quick reminder. If you're on the stream right now, you can use ISC or Twitter to ask questions. We have a human computer interface here, just for your convenience. Microphone number three, please. Hi. My question is, does the operator have any incentive to block media tunneling? Like, is it not more expensive to tunnel data through what interface then just use the data services? OK. So for now, since media tunneling, the bandwidth of the media tunneling is very low, so we may think that the operators does not provide that attack. But actually, so maybe operators in the future may increase the bandwidth that bearers the bandwidth because they will start another services that requires us more bandwidth. So in that case, they will private the media tunneling. But it cannot be simple to private the media tunneling method. Microphone number four, please. Hi. Congrats on your findings. I'm guessing that you've looked quite some time into the DIAC interface of Qualcomm. So basically, what you show is there's just a command that you can read and write to any memory address and just do whatever you want. So basically, that gives you RCE. And is this possible on any Qualcomm baseband? The answer is no, because to send DIAC commands directly, your phone should be connected with your laptop or your computer. So you cannot perform any RCE attacks. But if there is a vulnerabilities on that system, then you can locally exploit that. But what I mean is, suppose you have root permissions on your Android phone, you've rooted it, and you want to go deeper into the baseband. You can just send DIAC commands to it, and you could just read and write from any map. Yeah, so actually, we tried, but some of the DIAC commands were blocked. So we couldn't actually change the memory addresses. But there is operational code, but the DIAC system in the CP is currently blocking those commands. OK, thank you. Number two, please. Hi. I did some previous security research on voice over IP. And much of the vulnerabilities you described also apply on traditional voice over IP networks. For voice over IP, there are security standards. It seems to me the providers in Korean and America doesn't have the security guidelines in place to prevent these attacks. Is that correct? Actually, because we are not the operator person, so we don't know the exact thing. But when we tested the vulnerability, it was there. So I'm not sure. So after our responsible disclosure, they are trying to. Yeah, after we reported, they are patching with us, and they are currently making those guidelines. Yeah. OK, thank you. Number one, please. Yes, I was wondering about call session management and how resource-intensive it can be on the server side. Has there been any considerations how to solve it? You mean to solve the session management? On the server side. On the server side. But I think it's quite simple, because if any user makes a call, then the SIP message is you should send the invite message to the SIP server, right? So the SIP server knows which user is now calling. So if you check if the state of the user, then you can just log other invite messages after the first invite message. Then I think that will reserve the problem. Yes, I was just wondering about the resource-intensiveness. Then this is going to be for the operator, handling so many sessions at the same time. But thank you. Number three, please. My other question is, you mentioned you had some efforts on reverse engineering, the DIAC protocol. Were you able to open source your efforts? And if yes, where can we find it? But actually, there are several documents already in the Google. Actually, we got the operational calls by Googling. And we reverse engineered the USB protocol by just snapping all the USB packets. So later, if we fully analyze the systems, then we can disclose those. Signal angel, please. Thank you. Is it possible to not use the operator's IMS at all? So can you configure your own voice over IP network and talk with friends by using direct IP? Can you repeat one more time? Sure. Is it possible to not use the operator's IMS at all, just to set up your own voice over IP application and talk to friends? Yes, you can utilize your own VoIP system. But the fact the operators are providing VoLT system is that they want to provide higher priority services. Because if you utilize your own VoIP system, then you use the data interface. But as I mentioned before, VoLT interface has a higher priority than the data interface. So there is no QoS on the data interface. So that's why the operators are providing those VoLT features now. So the answer is you can implement your own system, but you cannot guarantee your bandwidth or that kind of things. Number four, please. I'm interested in the kind of arguments that you presented to the operators. So they fixed it. Because when we report those kind of vulnerabilities in VoIP and VoLT networks to telcos, they just don't care because the time that they will spend implementing CPS, SRTP, or authentication, they consider it an advantage that they will lose regarding their concurrent. And do you think that going through SRT kind of forced them to act upon the vulnerabilities that you reported? I'm not sure if there is a legal issues that SRTs can force the operators to apply those security mechanisms. But the fact that Korean operators are patching that fastly because there are Korean news systems. So we reported to the news. And because there are several citizens who claim the operators, so they patched that fastly. So the power of citizen maybe help. OK, thank you. Internet, please. Thank you. Question. If you spoof your number, will it also set the P-asserted identity header field, or will that be overwritten? The P-asserted identity header field. Don't shoot the messenger. I don't know what it is. Can you repeat one more time? Sure, sorry. If you spoof your number with your application, will it also set the P-asserted identity header field, or will this be overwritten? The P-asserted identity field? Yes. I'm not sure, but yeah. Because there is only phone numbers in the SIP header, you can just change your phone number to others phone. And you can also change your IP address to others. Then you can just do a color spoofing. Do we have any more questions? There's also microphones back there. I don't know if you noticed, but you have them on top too. So OK, in that case, please once again thank our speakers. Thanks.