Transcript
Thank you very much. It's very cool to be here. I hope you will have a good time together. So my name is Elad Shapira. I'm a mobile security researcher working for Jamf. I'm part of the JMF team, Jamf Mobile Forensics. And today we're going to discuss mobile attack surface and how nation state actors are playing cat and mouse with your mobile devices. So here's important information for us to be aware. You need to remember that the attack surface and the vectors I will show today can be varied from a mobile platform to a mobile platform. It can be varied from the impact it has, from the chipset, from the hardware, from the vendor, from the version specific. But we would like today to discuss and enrich you with what's going on in the ecosystem of the mobile platforms. So let's discuss it. So first we need to remember that mobile devices are not just an app platform. They are more like a layered system of components. It has firmware, radios, hardware, kernel components, system services, and also applications. So we usually consider mobile device as application, but it's more complex than that. And attackers move and try to move between these layers to find vulnerabilities, to find attack surface, and then to try to see how they might be able to go between these layers. What's also important to note is that modern attack vectors or modern attack campaigns are not single bugs. They are more chain of attacks. So usually you don't have one single bug to compromise a full device. Usually you need to try to hack or attack or target a specific component as part of the mobile device, and then try to have a kernel privilege escalation or a sandbox escape in purpose to have more access to data or to the device. Today with us is Nir Avraham. Nir is the general manager, also the VP research of the JMF. This is our lovely dashboard. What we do is try to help you protect your mobile devices from various attack vectors on the mobile device. To see if there are indicators, to see if there are indicators of compromise. For example, zero clicks attempts, and we'll now deep dive into more technical stuff. Let's dive into the mobile attack surface playground. The first one is the browser engine. In this vector, we target the browser engine itself. It can be Safari or Chrome or any WebKit component that lies within the applications. The user interaction here is minimal. The requirement is minimal. Usually only a link, when you need to press a link, click, and then to infect the browser engine. So what happens? You click on a link, the page loads, a malicious JavaScript executes, and then a memory corruption vulnerability, which is usually a user at the free or type confusion, happens and gives the attacker code execution access in the rendering process. We see on an ongoing basis multiple, for example, V8 vulnerabilities on the wild, and also from other platforms, we see that attacks are considered highly sophisticated. This attack vector is more reliable because your device and this component needs always internet access to contain data to the device. So it's more reliable to have it on the device, and attackers are targeting this component more than others. And again, modern attack chains are not single bugs, they are expert chains. Here's another, message gaps. It's also one of the most reliable initial access vectors because it automatically processes the untrusted content. Every time a user receives a message where there is an image, a link, a file, it passes automatically in the background, and then it abuses the vulnerability. So we need to remember that the passing layer is very complex and relies, for example, on image IO on one mobile platform and also native media codecs on others to pass the content of the files that we get in the message gaps. So this one can trigger remote code execution on the device, on the message gaps, and what you need to remember, this is only a delivery vehicle to get. This is not the attack itself, it's just the way that the message gaps handle the file and then how it's being accessed by the attacker. In addition, what I said, it usually needs a second stage, because normally the message gaps give you control or access to a specific area, and then to get more data from the device, it usually needs to combine with kernel exploitation or something like that. This vector represents SMS or MS, one of the oldest and historically most dangerous attack vectors. It's care-delivered SMS or MMS. And unlike phishing links, what happens is that these messages are processed automatically by the device because it needs to understand what is the type of the message that gets into the device. Is it web? Is it text? Is it media-related? So we must inspect the basement or the telephone framework. We need to inspect the message in purpose to understand how to pass it. So that means that the passing happens before even the user is aware of it or needs to do something. Right now, we have RCS. It increases or enlarges the mobile attacks compared to SMS or MMS. It upgrades the traditional SMS with more functionality. It gives you more capabilities like messaging or email style, because the messages are being looked or viewed more like email. So it gives you the ability to do more spam attacks because it's more convincing to get a message with RCS. And recently, a major mobile platform also released an update to this kind of handling because the problem was when you're talking between two different mobile platforms, there were issues when we have on one side one mobile platform and on the other side different mobile platforms. So right now, it's being also handled from a security perspective. So this fragmented implementation was a little bit problematic and also the encryption while being done in the process. So this can reduce risks like interception or spoofing and spam on your device. Wi-Fi chipset or firmware, another vector. Right now, we are no longer in the application layer. We are now in the radio layer below the operating system. When you talk about Wi-Fi, we need to remember in mind proximity. We need to be physically in the area of the mobile device where it's connected to the Wi-Fi and purpose to infect it. So the device automatically parses or processes management from a network data, manager frames, beacons, and the handshake traffic. Even the user does nothing. It's always happening in the background. So this makes a potential zero-day attack surface to the attacker. For example, a few notable examples can be highlighted. The MediaTek chipset, which allowed remote code execution via crafted Wi-Fi frames. CVE-45569, also in Qualcomm WLAN components with a CVS score of 9.8, which is considered very severe. So these are memory corruption issues in the driver or the firmware itself. Another one, the Bluetooth stack, is another important proximity attack surface on mobile devices. But unlike browser or messaging vectors, the attacker does not need internet connectivity. It only needs to be physically near the mobile device, between 10 to 100 meters, to get interaction. And in recent years, attack researchers found that memory corruption variability, for example inside the Android Bluetooth stack, can lead to remote code execution without user interaction. We can see a few examples. And the attacker only needs to send a crafted Bluetooth message in purpose to get some kind of infection on the mobile platform. So we need to keep in mind, because the Bluetooth runs with elevated privileges, if you get access to the Bluetooth stack, when we get, as a result, also elevated privileges. Another one, cellular baseband. This one is one of the most powerful mobile attack vectors. The cellular baseband or modem. It processes cellular traffic directly from the network. So before mobile platforms ever sees the data. It means that exploitation can happen purely over the air. So without a malicious app, without a link or user interaction. And we saw a few documented cases where attackers were able to send malformed cellular protocol messages that can trigger memory corruption inside the modem firmware. For example, one notable example is CVE-282 in Mediatek modems. It allows remote code execution with no user interaction required. And also, Project Zero, if you're familiar with the team of Project Zero that finds many notable attacks of vulnerabilities, they also published regarding axonious modems in Samsung. And we also saw other mobile platforms that patched baseband-related flaws. SIM or e-SIM updates. This one introduces the hardware level attack servers where specially crafted OTA binary SMS messages can trigger a SIM toolkit. It's called the SDK component. Directly from the UACC, which is like the hardware physical SIM data on your device. So it bypasses controls of the mobile platform. We can mention also SIM Jacker, which exploits the SAT browser applet to perform a silent location of the user that's holding the device. And also, Swim Swapping is a carrier-level social engineering to take over a number or duplicating a SIM where we would like to get the credentials with physical access of the SIM card. This targets the ownership of the SIM card. We need to remember that these attacks are sometimes harder to detect in case being done because there's interaction with other layers of other holders of the attack in the process. SS7, it's a legacy telecom signal protocol. It's built on trust model but no longer holds. It's a little bit vast for a lot of time but still used. It allows hackers or attackers to network access to send legitimate-looking signal message. So this message can track a device location, can redirect SMS or intercept authentication codes. So attackers love to find or use SS7-related vulnerabilities. So this one, we need to remember, it happens only on the telecom network, core network, and it's not on the device itself. But if our device is part of the network, it's also important for us to understand and be aware of the whole ecosystem of the mobile device. So even a fully-patched smartphone, it's hard for it to detect from this kind of attack layer. Another one, Rogue Base Sessions. It has a lot of names, IMSI catchers and a fake cellphone tower. It's usually a journalist or researcher published on a sensitive location, wherever there's an apartment, that equipment can be found in the device trying to attack or target specific individuals or companies or important people. For example, near government buildings. What happens is that our device tries to connect to a nearby cell tower. Automatically, we trust the nearby cell tower. So if we come as an attacker and bring our own cell towers, the device might connect to our, as an attacker's perspective, to our cell tower, the rogue cell tower, instead of the legitimate one. And then we're able to have attacks or target the device because we also can get the IMSI value. It's like the SIM card number of the target or the person that connects to the rogue cell tower. Let's do something interactive. If you have your phones, can you check now if you have a fallback to 2G network inside your phones right now? In your mobile carrier, open your device now and see if you don't have connectivity, if you have a checkbox enabled that allows you to do a fallback to 2G networks. Can you do it? Verify, because 2G allows weaker protocols and no encryption can be even disabled by the attacker. So we can jam the networks and try to get you to be decreased to 2G and then have more attack surface. So if your device, which is updated and new, it also might be able to surf on 2G. So then we target the network itself. So this device is also used by law enforcement and also cases where it's used by criminal operations. Anyone found 2G? Okay. Another one, proximity attack on NFC. This one mainly targets the mobile payments in the device. So unlike Wi-Fi or Bluetooth, the NFC attacks usually do not rely on complex zero days. So the attackers would only like to get the NFC data of the payment. So it's usually from the info of the card or from an app that can read it. So the malware reads the NFC data. It sends this back to the infrastructure of the attacker, then uses it for payments without having the physical device. And we saw a few campaigns that abuses the NFC data or attacks. You can see here a few notable campaigns that were on the wild. So one notable attack is called relay. Okay? Relay attack. It's one common technique. Another vector, physical. We have a lot of vectors. So physical security of your device. For example, you go to the hotel at the conference. You go to the pool. You leave your device because you don't want it to get wet. And if you made the attack, for example, someone enters the room, then it tries to get your device hacked through physical. It's not easy. But we see, for example, a few examples published on the wild of attacks that target physical. It gives also, for example, forensics capabilities to companies that try, for example, to access your device. And you can see a few examples. How are you so far? Well, getting to the end of the part of the vectors. This one is supply chain or update channel. Your device and your application also relies on trust of the ecosystem. For example, an application uses third-party components or third-party libraries. So the app that you're using can be secured, have a pen test on the app, but it still uses a third-party component or library that is vulnerable to attack. And the owner of the app just uses it as a black box, as a component. Inside the app, it's not aware that it's not maintained. It has vulnerabilities. We saw also campaigns of this SDK. For example, the Goldstone SDK that has more than one million downloads in apps. But also we saw examples of targeted attacks where it tried to abuse the trust for updates. And another vector is that if we have access as attackers, we try to have a device with pre-installed malware before it comes to our target. If we have some access on the supply chain on the way. We saw also examples of this kind of vector. And the last one is, of course, applications. I will not deep dive into it, but it's self-explanatory. Applications do have problems, and also there are applications which are malware. Common malware on the mobile platform. They try to do stuff from attackers' perspective, steal data or give access. Here we can see an overview of all the attack vectors I mentioned. Again, it varies from mobile platform to mobile platform, from device to device version, from chipset, from component to component. It's being always a cut and mask game between attackers and the defense. And there's always updates, so attackers need to find new ways to get into the device or get access. Even if it's limited, or they need to glue a lot of attacks on the way. A lot of vulnerabilities or chains. So now, after we saw the mobile attack surface and vectors and ways into the mobile device, let's now deep dive into the way attackers try to keep their presence on the mobile device. Now we focus on what happens post-exploitation, after there is some control over the device. In the Alexa Predator, it's a commercial spiral platform that has been leaked to zero-day exploiters, but used to gain initial access, for example, to iPhones. So while conducting independent reverse engineering to the Predator sample, Jamf Threat Labs discovered several undocumented mechanisms that reveal how sophisticated these spyware anti-analysis capabilities truly are. So Jamf went to research this Predator, and there are some unknown, and we published it in our blog post. If you would like to know better on our capabilities, and also about the commercial spyware, you can reach out to Nir Abraham, again, he's here, feel free. So we'll now deep dive into a few examples from the Predator mechanisms, and see that it's not only relying on the anti-analysis check, but it implemented several environment awareness. So the Predator tried to understand in what environment it runs, and went to, let's say, for example, cut losses and avoid detection. So this one is the first snippet that was queried. As you can see, it has developer mode status, so it explicitly checks whether the iOS development was enabled. So this one is a strong signal, but the device may belong to a researcher or tester, because there's no common reason for a user to have this mode enabled. So the commercial spyware says, hmm, interesting. This one is enabled. Am I now running in an environment which is not good for me to run as a commercial spyware? So this one is significant because the developer mode was released in iOS 16. So specifically for researchers or developers. So by detecting this, the Predator effectively says, if you enable developer features, then it's probably not a normal target. So this one, one check. Here you can see another check. The second snippet is, as you can see, it's not phone logic. So it looks for classical jailbreak artifacts, such as CDA or APT paths or binbash, and other non-stock faulty system indicators. So the commercial spyware tries to understand, okay, is this a jailbroken device? Hmm, it's interesting. If it's jailbroken, maybe it gives more access to the researcher to see what I'm doing, so it's better not to continue to run. The third snippet, if you can see something interesting, it queries the NSLocale. You can see two texts of countries, US and IL, which is the United States and Israel. So the commercial spyware tries to understand and compare the device country code against these countries to see if it's matched and then to trigger a dedicated error path. So it tries not to avoid being run in these countries, as you can see. So what we saw that it's not just trying to avoid technically analysis, but it's also trying to see what is the environment, what is the geographic location, what is the current device capabilities, and then to see if it will continue its functionality. So now we'll deep dive into more examples, and this one goes beyond anti-analysis logic. It goes beyond environment checks and more to anti-analysis logic of the person that tries to verify what's going on with the commercial spyware. So it moves capabilities of more active analysts and anti-forensics capabilities. Okay, so far so good? So the snippet, if you can see, it tries to query if there is a console attached to the mobile device. So okay, there's a console attached, it's being debugged. It's being debugged, okay, interesting. It's a red flag for the commercial spyware, but the device is right now being debugged. Maybe it's being monitored. Here you can see another example. I don't know if there are network people here, but Netstat is very familiar, but Frida Server, it's a common research tool. For example, I use Frida a lot in analysis, and also TCP dump, which is also monitoring related to network. So it checks if various monitoring tools are being connected to the device to try to see what's going on in the network perspective. So if it detects both professional reverse engineering and tools, and the more basic network tools, then it gives also a red flag to the commercial malware from that perspective. And another example, if you can see the crash report mentioned here, in the snippet, it's also trying to look for this routine. It's trying to watch a crash report, so maybe it indicates the predator that it's trying to detect or interfere with the crash artifacts on the device. So it might expose its behavior if somebody tried to look at the crash reports. Okay, so this is another example. So we have also environment-related checks, and also we saw debugging or analyst-related checks from that commercial spyware predator, which was not only full capabilities, just a few examples. Now we move to the post-exploitation stage. This is after the predator is on the device itself, and what you can see, the device has already been compromised, and the jump for Threadlabs, we showed how the predator on iOS hides one of the Apple's main privacy protections. Do you know what is the green dot and the orange dot on a mobile device? Microphone turned on or camera turned on? Exactly. So these indicators are usually controlled by something called Springboard. It's the core iOS interface process, but predator does not shut down the phone or fake black screen. For example, in the notable attacks called No Reboot, where the device seemed to be rebooted but still active. In this case, the predator keeps the device functioning normally, but only hooks the indicators visible to the user of the orange and green indicators of camera and microphone. So it hooks them, and the user thinks that it's not being recorded, but it actually does being recorded. It keeps the surveillance much harder for the user to be aware of what's going on in his device. Here you can see a few examples from the JMF solution, where we give information to our customers when we find examples of commercial spyware or attack attempts on the mobile devices. It's a mix of mobile platforms. There's no just support for one specific mobile platform, but we support the major ones. So again, if you would like, we have a session later, shortly after this one, with Nir, and we might give more valuable information about what's going on. It will be very interesting. As I can recall from previous JNL, I attended it. So now let's talk about the future. AI is being used everywhere. I use AI all the time. You probably use it. Also malware. Autos also use it. Attackers also use it. And it's another game of cat and mouse game between attackers and defenders, where AI versus AI. And we see more examples now that attackers try to bring capabilities of AI to the malware. So it also gives credits and it queries the infrastructure with tokens and queries. What to do? I'm in the device. Okay, so it gets back commands. Check what's going on. Talk to the user. See what's going on. Give data. And automatically, being done. Okay? So we see more examples here. For example, each unique on its own, but you can check it later. For example, prompt spy, surks, rat. And also, you have, for example, something called Termux. It gives more capabilities in the automation on the device and gives attacker easiest way to perform an attack using other components. So it's very cool to get familiar, not just because if you're an attacker on a mobile device, just as a regular user, but you would like to be aware of capabilities, what's going on. Okay. So, thank you. I hope you learned something about the mobile attack vectors. You can reach out to me here. I'm available after the talk. And also, Nir Avram is here. You can reach out. And also, we'll have a good time with them if you would like to see something cool later in the next session. Thank you very much. Thank you, Elad. Thanks a lot. That was the last official session in here for today. Thank you all for your attendance. We will have some other drinks, some more food coming around by 5 o'clock. In the meantime, by 4 or 4.15, depending on the locations, we will have some other breakouts, some other small sessions. If you would like to attend or to join, let us know or go to the booth directly. And we'll go from there. Thanks all. And have a great day. Thank you.
