 Let's give Rowan a first time speaker a big round of applause. You get to keep one. Have a good time. Thanks. Hi, so my name is Rowan. I'm an undergrad at the University of Washington and last time I was doing research into using Thinsims to break mobile money applications. So first, what are mobile money applications? So, if you've ever used Venmo, then you've probably used a mobile money application. The basic idea is you have a balance that you can load money into, and it's usually some form of app, then you can transfer that money to other people and make payments through that way. Now, the ones you've probably seen all run on smartphones, but it's possible to run these things on the SIM card of a phone or over other means. So they're actually very widely used. So there are almost 700 million accounts worldwide, 276 deployments in 90 countries, and transfers that were a billion dollars a day. Now, a lot of these users don't transfer very much money, though. It's $188 a month, which, on average, and that's because they live in places where they don't make much money. So these applications are very widely used in places like Africa and Southeast Asia for people who don't have access to banks. And the reason why they'd be using this over banks is that banks are a lot rarer, and so here you can see there's roughly 500,000 banks in developing countries, whereas there's 2.2 million mobile money agents. So all you need to be a mobile money agent is just have phone and have access to cash. So the infrastructure required is a lot lower. So it's a lot easier to get access to it. So if you're a farmer and the nearest bank is a couple of villages away, you probably would not have a bank account with a bank because it's going to take too long to get there. And so the only way you could store your money is by trying to keep it safe somewhere, so maybe burying it at the ground, and that has its own issues, like maybe you lose it, gets stolen. So mobile money is actually a really useful tool for these people to try and be more financially secure. And so it doesn't only run over smartphone apps. The most popular interface is USSD. I'll explain what that is later on. Then there's smartphone apps. Then there's SimToolkit apps, which run on SimCard. I'll explain those as well. And then there's IVR. So the interface is offered by these platforms. So most of them offer USSD. So this is the trade-offs between the different forms of applications. So you've got smartphone apps, which everyone knows what a smartphone app is. It's got a very rich UI. It's very easy to develop for this existing development environments. It does not require any cooperation from the phone company. You can just load an app on your phone, start running it. It needs a data connection, which can be a bit difficult to get in some areas, and also requires a smartphone, of course, which comes with its own host of issues. Which means, you know, then you have to be able to charge it every day. They're fragile. If you break the screen, that's a big problem. So they're not so useful in these environments, since most people also don't have smartphones, because they cost money. So then you've got SimToolkit apps. Now, these run on any hardware. So that's good. They also don't require a data connection. They usually use SMS as a backhaul or as a connection back to the service to make things happen. They've got a menu-based UI, so it's visual. It still requires a lot of cooperation from the phone company though, because the application needs to be on the SIM card. So you also need a special SIM card that has the application preloaded. And this can be difficult if, for example, you are not the phone company, and trying to convince them to put the app on the phone. And then there's USSD, which runs on any phone. Again, it's built into the GSM standards. It does not require any special SIM card. It's got a very standardized UI. It doesn't require data. It still requires carrier cooperation, because the phone company has to set up the gateway to allow your application to actually run and give you the number for people to call. However, it only provides a text-only interface. In experience though, people don't seem to care about this. They don't mind using text-only. They've figured out how to use it in a very fast and efficient manner. So we all know what SIM cards are to some degree, but just to go over it, they identify you still in the network. They can authenticate devices on the network. They can do call control, which again I'll explain later, and they can run the SIM toolkit applications, among other things. So SIM toolkit applications run on the SIM card. They consist of menus and input prompts. They can also send SMS, place calls, which cell tower you're talking to, get the phone's IMEI, which is equipment identifier, and a few other things as well. It's defined by a GSM standard as well. So this is an example of what they look like. So on the left you have a SIM toolkit app running on a smartphone. So you can see you've got menus, you tap on a menu, and then it might pop up a prompt asking you for text. And then on the right you've got it running on a feature phone or a basic phone. And so then it's still got very similar UI, except you just navigate it with the keypad. So this is an example of message flow from mobile money application. It's a little modified, but the idea still stands. So what you can see is that ME is mobile equipment, so that's the user's phone, and the SIM card is the SIM card. So what you can see is that all messages always start from the phone and then get sent to the SIM card. So here you can see the phone is telling the SIM card that someone entered into an application with this ID. The SIM card then says, great, select an item from this menu. The phone says, here this is what they selected. The SIM card then asks for the user's pin, the user provides a pin. The SIM card will then go and connect to the network and make the payment go through. In this case, it's just hand-wavy, but usually this is done through some form of encrypted SMS. And then the SIM card will then display the balanced user and the user will terminate the session. So this is what the messages look like. To TLV, you've got the tag, the length of the body and then the values. So the SIM toolkit commands always start with the D0 and then the length. Then you've got the command details tag, so this will tell you what command is being sent. Then you've got the device identity tag, which I feel is a bit redundant because you can already figure that out from the command details tag, but it basically just tells the phone where the message is coming from and where it's going. And then you've got various tags associated with that type of message. So here you've got a text string tag. This is just saying that they're trying, this is just by texting the screen basically. So then you've got USSD or Unstructured Supplementary Services Data. So it's dialed like a voice number. No record is stored on the device, however. So while you would dial it with the same phone application that you would usually use to say call someone, usually there's a call log associated with that. So you can go back and see which numbers you've dialed before. USSD doesn't have that, so there's no way of going back and checking which USSD number someone has dialed. It provides text on the interface, and here you can see it running on a smartphone. This is an application we were using for testing. So this is the format that the numbers are in. So it always starts with a star and the numbers and a pound, then a pound sign. So the first one would just connect you straight to the service. Now if you know the service always pops up the same menu when you get there, and you know you want to enter in one in the first screen, then you can actually just append star one to the number. And then that means it'll enter in one at the first menu prompt and it'll skip straight to the second one, assuming one is valid input for that. And you can chain this many layers deep as you want. You'll get stuck though if you make a mistake and then it will repeatedly try the subsequent numbers on the same screen, which can lead to unexpected behaviour. But you can chain it as many layers deep. So in theory you can do an entire transaction of going through many, many screens just in one command. And this is how most users end up using this service. So now for thin sims, which is what we were actually using in this to do these attacks. So you can see they're very thin devices, they go between the SIM card and the phone. I have some, people want to have a look at them later, but can't really hand them around. So they fit any size SIM card. So you can see we've got the ones on the left are the ones that we were using for testing. They require cutting out a corner of the SIM card and as such they can end up used with mini sims. The ones on the right, you see they've got different, they're much smaller and so they can work on both nano and micro sims as well as mini sims. So they're field installable. This means anyone can install it. You don't need specialised equipment. It's kind of like a screen protector in terms of installation process for some. Then they contain all the functionality of a SIM card. I mean they're just running code so you can write anything you want onto it. They're free from carrier restrictions and therefore they allow third party applications. This is also useful because the phone company isn't the one putting it in. You can put any thin SIM you want into your phone and then they can read and modify all the communication between the SIM card and the phone because they're sitting on the interface. So the original use case for these was cell phone unlocking. So back when you had a GSM phone that locked to a network, you could put a thin SIM into it and be able to use the phone on any network. Which was very useful. Then the other use case we've seen is distribution of apps. We'll talk about an example of that as well later on. For example, if you're a company trying to put an application into a SIM card and the phone company doesn't want you to put it on, then you can use a thin SIM to get around that. Finally, there's the case of distribution. This would be most of these attacks involved being able to steal money from other money applications. Say you're a shopkeeper and you want to make a bit of money on the side, you run a phone repair business and you're trying to make a bit more money, you could put a thin SIM in and be able to scrape a bit of money off the top. Not recommending this by the way. Let's look at M-Pesa. M-Pesa was founded by Safari Common 2007. The original way it was founded was that they would charge codes that would add balance into their accounts. They would buy these codes and then send them around as a form of payment. In a change of services, you would then send someone say a $10 recharge code that they could either reply to their account for $10 of airtime or sell on to someone else. Eventually, someone might sell it back to a shopkeeper who would sell it to another user. Eventually, Safari Common realised this and which was a mobile money application and cut all this out of the loop and make it a lot more streamlined and safe for the users. Today, it transfers 24% of the Canadian GDP each year. It's very widely used. It's expanded to many other countries and it definitely runs over SIM toolkit application. It's not necessarily currently the primary way it runs but it's definitely run over that in the past. Then EquityBank came along in 2015. They wanted to run their own mobile money application. They came along and because they wanted more people to be able to use it, they couldn't run it on a smartphone app. They needed to use either a USSD or a SIM toolkit and for whatever reason they decided to run it on a SIM toolkit application. Unfortunately, Safari Common had 80 or 90% of the market share and of course they didn't want to put a competing market share on it. So as a result, they forced EquityBank to try and distribute their app as a thin SIM. So there was a court case about this with Safari Common trying to stop them from doing this. The court eventually allowed them to do it but there was very little, no one really looked into the security implications of this. So here you can see a phone with a thin SIM installed and an app running on the thin SIM. So you notice that this is all fine, no data is really at risk here. Then when you've got application running a SIM card however, this diagram makes it look like the data is traveling from the phone to the SIM card. But really what's happening is it's being sent from the phone to the thin SIM. The thin SIM is then deciding to forward it onto the phone and then the SIM card can process the data and send it back. But the thin SIM is processing all the data as it goes through. So there's probably some fun things. What if the thin SIM is not friendly? What if there's some malicious code on it? So there's a lot of things that the thin SIM can do. Let's just look at the first three for the first attack. So this is the ability to intercept, modify and create SIM toolkit commands, then view the response to those commands in plain text and then the ability to send SMS messages without notifying the user. So this attack was primarily targeted at the SIM PASA SIM toolkit application because we needed a target platform. We also did some testing against air teller and some modifications just because it's got a different menu structure. It would work against that as well and probably any other SIM toolkit based mobile money platform. So the attack takes place in two phases. You've got first we steal the credentials and then we actually make the fraudulent payments. So you've got the phone, the thin SIM and the SIM card. So initially there's a transparent and the user is using the SIM toolkit app and it's completely it's not clear at all there's a thin SIM installed, they can't tell. They're just using the SIM toolkit app on the SIM card everything's normal. Eventually the app will ask the user for a pin and at this point the thin SIM will start listening then the user will respond with the pin and the thin SIM stores the response. At this point the thin SIM is stored their credentials for later use or anything about it. So then we have demo. So this is me entering into the Mpacer app. So first I check to see there's no so let me just start this again. So what I'm going to do is first verify there's no pin stored then enter into the Mpacer app try and check my balance and then view the pin afterwards to show that it's captioned. Now unfortunately they don't use them for too long they become they're no longer active and so this one we didn't use for too long and as a result it can't actually send SMS messages but the attack still proves the first half of the attack. So here I go and view the pin that is stored it says no pin is captioned. So then I go into the Mpacer app navigate through some menus check the balance it then asks for the pin says okay and then it fails to send the SMS because it's not active on network exit out view the pin and now we have the pin stored. So back to slides. Okay so now for phase two this is where we actually go and make the fraudulent payment. So again you've got the phone, the thin sim and the SIM card. Now these status updates are sent roughly every 30 seconds from the phone to the SIM card. We're just using this as a way to trigger the attack although it could be triggered through various other means. So once the thin sim decides it wants to start the attack it then begins a transaction it begins a sim toolkit session with the SIM card. In this session it goes and sends all the data required to initiate a transaction. The data sent is exactly the same data that the SIM card would expect to see if the use was interacting with the SIM card. Eventually the SIM card will then try and contact the network. This is via sending an SMS. Now usually this would pop up a notification on the screen. However that would tell the user something weird is happening and they might be able to try and stop what is going on. So let's see if there's a way around that. So here you can see this was one frame taken out of the previous video. So the SIM card was active it would have been more obvious what was going on but here you can see that there is a message at the bottom telling the user that the application is sending an SMS. Now the application can specify the string. So here we've got the message that was actually sent. The SIM card sent to the phone to make this SMS happen. So you've got all the stuff at the start with the command details and the device I don't need. And then you've got this text string and this is what is actually displayed to the user followed by the SMS TPTDU which is the body of the SMS and where it's going and all those boring things. So how can we make this go away? Now you might think oh let's just remove the text string and maybe it will disappear. Well unfortunately that leaves up to the phone to decide whether it wants to send, display something to the user and most phones will display something to the user telling them that an SMS is being sent. But however if you just give it a null string so just tell you've got a string of zero length nothing shows up and so then you can send an SMS without the user seeing anything. So that's what we do. So if we go right back the SIM card is trying to send an SMS the thin SIM takes the message removes the bytes that would make something show up on the screen replace it with a zero length string and then sends a silent SMS that doesn't show up to the user. So what this looks like so let's start again. Alright so what this looks like to the user is just verify we've got the pin stored and then we start the attack then the user won't see anything unfortunately because the SIM card is not active it will still show the failed send SMS but the other messages didn't pop up ahead of time it's there in the it's there in the logs and the ability to send silent messages is shown in another demo as well. So that's that's the oh no. So at this point we've successfully done the transaction and there's no indication to use that the money has gone anywhere or anything's happened really at all. Cool so let's go back to the list of capabilities we have. So we've already used the first three so let's look at the next two. So the ability to log in redirect calls both for voice and usd and the ability to make usd calls and the ability to use it. So this is done by call control so what call control is is whenever you dial a number to call on your phone first the phone will actually ask the SIM card so say you then ask the phone ask the SIM card hey can I call this number and the SIM card will respond yes sure here you go you can call the number however the phone the SIM card can also say no you can't call that number and just deny it outright or it can modify the call and say sure you can call a number for this one instead. Now interestingly for voice calls depending on the phone this mail may not show up and the call log is being redirected on the android phone we had it did show up as being redirected however on the feature phone we were testing on from 2005 was running some windows operating system it didn't show up and it showed the original phone number so this doesn't sound too bad right we can just it's just messing with what people are calling with this because usd is not usually tracked maybe you're using a usd service that you wouldn't want other people to know you're using for whatever reason so if you had a thin SIM installed that was looking at call control it would then be able to see who you're calling which can then be used for advertising surveillance blackmail whatever you want it could also use the phishing attacks if you're ever trying to set up a fake customer support line and trying to get someone to call it this makes it a lot easier you just make them call the original customer support number it redirects to your own number and then you can get away with whatever social engineering attacks you're trying to do you could also route all their calls through some premium number and just make their phone bill go really high and charge them a lot of money that way of course it would be a premium number that you own so you get the money for it or you could redirect to usd calls let's see what happens if we do that so for the usd attack it takes place in two phases however this requires attackers to set up their own usd service which the other one didn't require the attackers to set anything up and depending on the country setting up a usd service can be anywhere from easy to almost impossible for example in the US no one really uses usd I've never seen any usd sessions the closest I've seen is for example the AT&T your dial star, data pound and then it will send you an sms back with the data usage you've got for that month so this is the setup we had so we've got laptop running the osmocom network in a box which is a cell software a cell tower software unfortunately no out of the box cell phone software I could find was open source had functioning usd capabilities so we had to modify it a bit with various patches from various years it worked in the end then we've got usrb b210 which is actually the radio we're using then you can see we've got a phone sitting there with a development module thin sim plugged into the back of it and then a debugger attached so I can view the messages that are actually being sent between the phone and the sim card for debugging purposes so here you've got a phone, the two services you've got the legitimate one that the user is trying to access the attacker service that they've set up and then you've got the thin sim the next thing the user is going to try and do is they're going to try and dial the number for the legitimate service now this initiates call control tries to ask the sim card cannot dial this number however because there's a thin sim installed the thin sim intercepts that and decides to redirect it somewhere else so it then gets redirected to the attacker service now the attacker service will mimic all the menus for the legitimate service perfectly so the user will go through all the menus they're expecting to go through and entering all the payment details however right before the very end of the message, right before the very end of the transaction that would actually send the money the attacker service will return an error because it can't actually make the transaction go through the user will likely interpret this as some kind of network connectivity issue and try again later at which point it would go through with no issues so we have a demo of that as well so in this demo I'm going to dial the number for our usd service and then it will redirect it to the attacker service so now I'm dialing for the legitimate service it gets redirected without telling the user anything so we go through and then enter into check and balance so we type 1 press ok so then ask the pin error could try again later so we exit out of this just mute that to try again I don't know why it takes so long to access the usd service it really shouldn't but it does send me growth room and we try to check the balance again so we enter in 1 check balance again we go and enter in the pin and now we actually get the balance so notice this is 9001 so over 9000 ok so that's the demo of phase 1 so then in phase 2 we actually go and try and steal the money so again this is triggered through some means in this case we just triggered it through a menu item in the simtokit application however again it could be triggered through a status update or something of the like so first the thin symbol call the attacker service because it needs to get the pin back so we call the attacker service and get the retrieved the pin so then it gets the pin back and then it will actually make the transaction so what it does here is it strings together the entire command it would need to do so it would be like star 1 2 3 star 2 to make transaction star and then the destination phone number another star then the amount that trying to send star 1 for confirm star and then the pin and then pound that's the string we need for this service in particular so we have a demo of that we go into the simtokit application so we select send usd it waits for a while because there's no it doesn't display to the user anything is happening usually it would but we've made it silent so now let's go and check let's check the balance to see that we've actually sent some money somewhere so now we go through and actually go and check balance enter in the pin again and now the balance is much lower this is sending a bit over 600 current units of currency somewhere to another account so at that point there's not really a lot the user could do the money has disappeared by the time they notice it's probably been shifted to another account or cashed out of the network so that there's no there's no method to recourse and customer service in these places often not so great so there's very little chance of users getting the money back so there are a couple more capabilities I didn't really talk about ability to track location updates so this is what telltale the user is talking to you could make some like some snooping software to track users doing that there's gsm authentication this is not really so much an attack but you can use it if you know the imzi of the device of another user and the key for the network you can then pretend to be that user and then you can read any data off the sim card including the imzi and the phone book that's stored there also in the gsm standards it allows phones to store sms messages on the sim card and in the case where that message is being stored on the sim card the thin sim would be able to read those as well as they went past so let's look at some possible defenses now so you could disable call control this would get rid of all the call control based attacks as well as the usd based attack because you simply if you can't redirect the call the attack is completely impossible however that requires modifying the phone standards and then updating all the phones which is not really going to happen because a lot of the users who would be affected by this don't have data and if they have data they want to use it for facebook and whatsapp that's what they're going to use it for and so they're not going to install apps they're not going to install updates it's probably not necessarily possible to install for updates over the air for these devices as well not all the companies that made the devices or even still around necessarily so then there's the ability to then disabling silent outgoing sms and usd well this wouldn't actually prevent the attacks all it would do is prevent the notification is make it clear to the user that something bad is happening now again unfortunately this requires modifying the standard and has all the associated difficulties so phone companies to put third party apps onto their sim cards this would then require a lot of cooperation from phone companies who may not want to cooperate and may have financial incentives not to cooperate in the case of safari comp this would at least make thin sims not normalize so if someone saw a thin sim at least then they would be very suspicious of what's going on you could use confirmation codes so if a sim took it in usd after the transaction has gone through then the user would have to enter in that confirmation code in order to verify the transaction and make it go through this works great for phones where the sms message is not stored on the sim card but if it's stored on the sim card then thin sim has access to it and so this is completely useless for those devices I don't know how many devices out there have that functionality so I don't know and for usd you could require the user to enter in confirmation value on the screen so this doesn't work because it needs to talk to the network but the essential idea is that once you start the usd session there's no indication the sim card can't interact with it anymore so if the session completes and gets to the end without having to require any more input the sim card then does get the response the final response that is sent back but if it needs more input it will then ask the user for it and there's a prompt that shows up so what this would mean is that the thin sim would not be able to completely predict the message that it would need to send and something would show up on the user's screen it would allow them to then deny the payment deny the transaction and stop anything from happening so this would be quite effective and finally it's a plain text interface and well there is actually a standard for that however of course no one implements this standard that would be too sensible yeah it's been around for many years but there's no implementation of it so there's a link to the paper that I use that was written for this presented at conference in June and then there's a couple of standards that there are does anyone have any questions if you buy your own sim card I mean you would so as a note for seeing those of the sim card yeah if you look at your sim card it would be very clear if there's a thin sim installed or not it's very obvious yeah however the interesting note it might be possible to do all these attacks if you actually had software running on the sim card itself so if you had supply chain issues for example you might also not be safe yep the I don't believe it's possible to get the key off the sim card if it was possible a thin sim might be able to do it um yeah it's not really something we looked into what else cool thank you