 Okay, so speaking of today is Taring says give me a big hand. Hi everyone. The title of our talk today is last mile authentication problem using which we are going to showcase how one can exploit the missing link in end to end secure communication. We will shortly dig into knowing what is the last mile, what is this missing link and everything. But before that, let me start by introducing myself and the research team behind this. I am Siddharth Rao. I'm a doctoral candidate in Alto University Finland and I research on security and privacy. One of the other hats which I wear is of public interest technologist. I was a Ford Mozilla open web fellow for the last year, as part of which I worked in an NGO called as European Digital Rights where I worked on the intersection of technology and society. Along with me, here I have my co-speaker Thangbui who is also a doctoral researcher in Alto University Finland, researchers on security and privacy. He just finished his summer internship in Google's security team. We also here have Dr. Marco Antikainen who is a seasoned security professional and a post-doctoral researcher in University of Helsinki Finland. We were supervised by Dr. Thomas Aura who is a professor in secure system research group of Alto. Okay, so now let's get started. We see network and software often with client server architecture. Let's take the example of browser and web server. In traditional threat model, network threat model, we always consider user device and the server and they are kind of typically trusted. However, the network is hostile and that's where an attacker can do various type of attacks such as man in the middle to steal information from the network. Since we are already aware of these attacks, we use cryptographic solutions such as TLS or WebPKI to protect it. Since you already know this, we are not going to bore with this. Because in reality, not all the communication goes over the network. Certain part of the communication, if not all, happens within the computer. So think of this as a network which is inside a computer. So the computer consists of multiple processes that perform different tasks. For example, software is broken into different components, say front end which handles the GUI and the back end which handles the local database. They are separate processes and they use a mechanism called as inter-process communication or IPC to exchange data between them. The communication whatever happens which stays inside the computer and it never leaves outside. There can be untrusted components that runs inside the user device and protecting the user information of the data being exchanged over IPC is equally important as that of the network. So for this reason, we try to understand the security of the communication inside the computer, mainly focusing on IPC. So in this talk, the title is last mile authentication problem. So those of you are aware of telecom or cell phone networks, you might be aware of the word that last mile. In telco, especially in case of landline, connecting everything from core network till the mobile switching center is considered to be easier than that of connecting the last mile or the subscriber line which lasts from local switch to your home's computer. Home's phone. And a lot of this to this, we are trying to encrypt and secure every strands and layers of the communication in a drive to move towards end to end secure communication. In that attempt, we are not even bothering about this last mile of which stays inside the computer, which happens, the communication between multiple processes. So the structure of the, this is what we call as the last mile and that's the problem which we're going to talk. So the structure of the talk is we first discuss a threat model, what we call as man in the machine or Mitma. And then we warm up with basics of IPC, it's kevets and attack vectors, which we use to exploit and show that there are several softwares which are vulnerable to Mitma. By going to different case studies of real life software applications that are vulnerable to our threat model, we also present some demos. We try to show that this is a real problem. Finally, we sum up with some mitigation mechanism. So the key takeaway from our talk is credentials and second factors that can be compromised inside a computer by exploiting IPC. As we show, we exploit many security critical applications such as password managers and USB security tokens using the aforementioned man in the middle adversary. All right. So let's get started. First, let's try to understand what is this man in the machine threat model? Who is this man in the machine? We call the attacker that try to exploit the IPC inside a computer as Mitma or man in the machine. The attacker can be any unprivileged user that tries to steal sensitive information from another user. The example of potential Mitma attackers include coworkers, family members and also guest accounts. The target system here is a multi-user computer, meaning the computer that can be accessed from multiple users, which are very common. So think of enterprise systems or universities where everyone will have the computer to which they log in using their own credentials. In such environment, even though everyone have their personal computer, they can be accessed by other domain users, of course, with their credentials. Interestingly, attacker can also be the guest user. In many OSS such as Ubuntu, the guest account is enabled by default and even the seasoned security professional forget to turn it off. It is important to notice that the computer here are not compromised or infected by malware. In that case, everything will be compromised. So we are not interested in malware, but we are interested in legitimate looking processes which are intend to be there on the computer. So the attacker's method is to run malicious process, but from another login session, not from victim's login session. An example scenario is attacker signs into victim's computer with his own credentials or using a guest account and run an even process. He then uses fast-switching or windows and leaves his login session in the background and switch back to victim's session. In Unix, commands like no-hook can be used to keep a process alive in the background, so you don't have to keep the whole user session alive. This way, the background session continues to be on attack in the background, and attacker's process is trying to steal whatever is happening in the IPC of another user. Things could be worse if there is a remote access to the computer, such as SSH or Windows, RDP, and everyone on it. And also it is important to notice that attacker tries no privilege escalation, even though in theory he can, but we didn't concentrate on that. The attack scenario is similar to that of impersonation or man in the middle in network, but in our talk, everything is happening inside one computer. So at this point, we might be wondering how to exploit IPC of other users to understand that let's dig deeper to know a little bit more about IPC and its kevins. Multiple processes inside a computer talk to each other using inter-process communication method. There are many types of IPC, such as signals, semaphores, shared memory, file system, network sockets, pipes, which includes unnamed as well as anonymous pipes. Some of them are unique specific, some of them are window specific, some of them are available on all flavors of OS, but they are implemented differently. Not all of them are vulnerable to attack model, but the common feature of the vulnerable IPC methods are that there is a server process which binds to a specific name or identifier and waits for the connection from the client. In that sense, we focus on three IPC methods, network sockets, windows, name pipes, and USB. So strictly speaking, USB is not an IPC, but still it is similar to that of sockets or name pipes, mainly because they also fall into the client server architecture and USB communication happens inside a computer, so that the midmer attacker can exploit it. IPC methods that are secure against our attack model, for example, is unnamed pipes. The difference is that in unnamed pipes, both the communication end points are created at the same time by the same user, so that leaves no opportunity for any untrusted process to get in midway. So let us now take a deeper look into insecure IPC methods one by one. Let's start with network sockets. Most of us think of computer networks when we hear the term network sockets. Even though they are used widely in computer networks, it is also one of the most widely used IPC methods. So here, network sockets are used when the server listens on a local host interface and they are bind to a specific port number. As long as the port number is more than 1024 because anything below 1024 are standard dedicated ports. As long as it is more than 1024, any process regardless of its owner can listen on the port. There will be one server process and multiple client processes that can connect. Also, network sockets doesn't have any inbuilt access control mechanism to restrict who can access the end point. This leaves the local attacker like midpoint to export them. So one of the obvious things an attacker can do is client impersonation. So attacker can find the port numbers either by documentation or source code or just by running commands like net stack. And he just connects to the local server on that specific port. There could be cases where the local server just accept one connection. So if the attacker comes late to the party, his request to join will be discarded. So in such cases, the attacker just impersonate the client process before the legitimate client does. So if client impersonation can be done, then it is also possible to do the server impersonation, right? Well, yes. The attacker has to just start the local server before the legitimate server does, mainly opening a specific port. There is nothing which can stop this. The client would not notice it and just simply connects to the port and start exchanging information. At this point, some of you might notice that legitimate and the malicious server cannot bind to a port at the same time. So does this mean that the attacker can do man in the middle along with client and server impersonation? The answer is yes. First, the attacker has to perform the server impersonation. That is, he runs the local server on a specific port. And once this primary port is open, he receives information, he receives connection from the benign client. Many softwares while running local servers like this fail over to another port if the primary port is already taken. So this property of port agility makes sense from development point of view, mainly because anyhow, these are not standard ports. So it could be one of the other legitimate processes in the computer would have already taken it. So it makes sense from development point of view to predefined list of ports where the server switched over to the second report. So what attacker does is he takes the advantage of port agility property. And what he does is after doing this server impersonation and blocking the primary port, he would allow the benign server to fall into the second report. And then in the second report, he performs the client impersonation. So in that way, he becomes man in the middle and he exchanges information between the benign client and the server. There could be rare cases where such port agility is not implemented. In such cases, the attacker can switch roles, time it well and exchange the information. It could be slow but it is still a possibility. So now that we know about network sockets on local host or vulnerable to Mitma, how about other IPC methods? Namepipes are available both on Windows and Linux. However, they differ in their implementation. We are interested only in Windows namepipes. In Windows namepipes have similar client server architecture that of network sockets. So instead of local host, here they are placed in a special path which is dot pipe which is in the root directory. And instead of the port number, here pipes will have a specific name. So all users including guest have access to this specific path. In network socket, there is always one server and multiple prints. However, in namepipe, there can be multiple instances of the pipe that share the same name. So multiple client server instances exist but in each case, there will be one server, one client. So every instance there will be one server and client pair. When the pipe process runs, it waits for the pipe client to join. Once the client joins, the pipe can create another pipe instance and wait again for the new client to join. New clients are connected in round robin fashion and the number of instances that can coexist can also be controlled. After the similarities, there is one major difference between network sockets and namepipes, windows namepipes. That is, windows namepipes are, they do have inbuilt access control mechanisms. Since pipes are windows objects, they have a discretionary access control list or DSCL associated with them. The word discretionary refers to the fact that object owner defies who has access to the object. So there are two cases. So when the pipe does not exist, anyone can create the first instance and set the DSCL of all the future pipe instances. Just because of ACL, it does not stop anyone from doing it. However, if the pipe already exists, then that is tricky. Only those users with something called as file create pipe instance can create new instances. So having access control does this matter at all to Mitmar attacker. Unfortunately, no. Similar to that of network sockets, Mitmar attacker can perform client impersonation. Any process can connect to an open pipe instance just by knowing the name of the pipe. Again, the attacker can find it from source code or documentation or just by running commands like sys internal tools like pipelist. So even though they are subjected to access control checks, like I mentioned before, eventually we will learn from a next slide that access control does not matter at all. Just like port hijacking or taking over the port before the legitimate server does, in network sockets, one can hijack, in name pipes, one can hijack the name of the pipe. By creating the first instance, we just hijack the name. And while creating the first instance, you can also set the DSL in such a way that it allows everyone to create or connect to new instances. Victims benign server here may just create the second instance without noticing that there is already one. And also there is a possibility of setting a flag called file flag first pipe instance which can be used to check whether the instance is created first or not. However, software developers seem to ignore this or they are not aware of it. Mainly because they underestimate or overlook this threat model. Similarly, benign client process can connect to the attacker's pipe instance without noticing who actually is the owner. It won't notice that it's not him, but the owner is actually some other person in this computer. So client and server impersonation can be done once the pipe name is hijacked. So it means that attacker can simply perform man in the middle. So there is no such thing of port agility here, like in network sockets, because every pipe instance used the same name, so MITM is just straightforward. Now that we learned about sockets and name pipes, what is common between USB? As I told, USB is strictly not an IPC, but here as well it shows client server architecture and it waits for a client connection. We are interested in a specific class of USB device called USB human interface which include peripheral device like hardware security tokens. In Unix and Mac implementation of USB is different from Windows. In Unix system USB, HID can be accessed by exactly one interactive user. So they have a mechanism where USB HID is actually a special file which is mapped in HID raw, HID raw path. And the logged in user get the default read read access. If the session is interrupted, or for example like log out or switch user, the read read, the access will be transferred to the display manager and then to the next logged in user. So in that way they ensure that exactly one user have access to the USB HID. Unfortunately in Windows, no such dynamic access control mechanism exists. So more than one user at a time can access the HID, especially of the other users. At least that is the case in terms of hardware security tokens. So before we jump into case studies, let me quickly summarize what we discussed so far. The attacker here is man in the machine or Mitma is an unprivileged user which also include guests. He does not perform any privilege escalation. The victim's computer is not infected by malware. The attacker's aim is just to intercept the IPC of other users. So the vulnerable IPC mechanisms are network sockets, Windows names, pipes, and USB. They all have client server architecture and they bind to a specific name or identifier and wait from the client to connect. The attacker can do client and server impersonation as well as man in the middle. The fact that name pipes have access control does not change anything. Now we will get into case studies to understand what will happen when the end points of IPC are not authenticated. So my colleague, Thang will present. Thank you. Hello everyone. So now I will show how we can exploit network socket, name pipe, and USB with real-world application. Our primary case study is standalone password managers. They are different from cloud password managers like LastPass in the sense that they provide native desktop app that allow users to manage the password. And standalone password manager, they are often integrated into browser with browser extension. This browser extension help users in creating and storing password and also entering the password into login forms. We are interested in the connection between the browser extension and the app because they communicate the password over IPC. The first case study I would like to talk about Roboform is a popular password manager and the Roboform app, it runs HTTP server on port 54512 and wait for client connection. The Roboform browser extension connects as a client to the app to and query all the password from the app. The problem here is that there is no authentication between the browser extension and the app. So it means that the app will accept any client without verifying if actually only ZT-made browser extension. So it's quite easy for the Bitmap attacker to exploit the channel. Since attacker is another user funding malicious process in the background, you just need to connect to the app as a client and query the whole database from the app. The app would happily keep always password without any verification. So this is a pretty simple case. Let's take a look at more complex case. So one password is another popular password manager. This is more interesting because the developer tried to protect the IPC channel, but it's not good enough. The one password app, it runs a web-stoppy server on port 6263 and wait for connection from the browser extension. And when the server got the connection, it verified the client very carefully. It takes the browser extension ID on the header of each request. It also checks the code signing signature of the client process to make sure that it is a known browser. And most importantly, the server checks whether the server and the client processes are owned by the same user. So this check, it prevents the Bitmap attacker from impersonating the client as a case of promo form. However, the client doesn't verify a server. Actually, it cannot because the browser extension is sandboxed by the browser, so it has access to very limited APIs. And to compensate for this limitation, the client and the server, they run an ethical protocol to agree on a share encryption key in the first communication, but the design of the protocol is not secure. Let's take a look at the protocol here. So can anyone spot the problem here with the protocol? So this is clearly not a secure protocol. As you can see, all the materials of the final key are sent in the messages. And also on step five, when the user confirm if the code match, you can see that the user only confirm on the app side. It means that a malicious server can totally skip this confirmation. So this insecure protocol, together with the fact that there's no server verification on the client side, allows the Bitmap attacker to perform server impersonation. And once the Bitmap attacker impersonates the server, it can send command to the browser extension and collect all the data that user enter on the web forms. So it means that user name and password that user enter on the web form will be sent to the attacker. I was supposed to show you the demo but because of the technical problems and I cannot really show it, but it will be on YouTube for anyone interested. So password manager also use a channel called Native Messaging to communicate between the browser extension and the app. So Native Messaging is a standard browser's viewing method that is designed to provide a more secure alternative to never socket. It has been used by many applications, including password manager. So how Native Messaging work with password managers? First, the password manager need to register an executable called Native Messaging Host with a browser and allow only its browser extension to communicate with its host. And when the browser extension want to communicate with the Native Messaging Host, the browser will run the Native Messaging Host in a child process and communicate with it using standard input and output stream. This way, the meat attacker cannot get into the middle and intercept information on the channel. So the question here now is, is Native Messaging a complete solution for password managers? Well, sounds like no, it isn't because the Native Messaging Host and the password manager app are still two separate processes. So they still need to HS data over IPC. The difference here is that the Native Messaging Host is not sampled by the browser. So it has more options on how to communicate with the password manager app. So let's take a look at another case, password boss. Password boss is a password manager that use Native Messaging. And on Windows, the Native Messaging Host use name byte to communicate with the password boss app. When the app starts, it creates a name byte when wait for connection from the Native Messaging Host. So Native Messaging Host simply connect to the name byte as a client and forward messages between the browser extension and the app. The problem here is that the app doesn't restrict access to the name byte. It allows all authenticated users to have full access to the name byte. This way, anyone can create a new instance or of the name byte or connect to it as a client. In addition, the app and the Native Messaging Host don't authenticate each other and all messages are sent in plain text. Because of these issues, we were able to perform manager middle on password boss. We could do it not only from an authenticated user but also from guest user. Let me first show how the manager middle attack could be done from an authenticated user. As I mentioned, when the app starts, it creates a name byte and wait for connection from the Native Messaging Host. So first, the attacker just need to connect as a client to the app's byte instance. The attacker then create another instance of the name byte and wait for connection from the Native Messaging Host. When the Native Messaging Host wants to communicate with the app, it will connect to the attacker's instance because it is the only open instance of the name byte. So after that, the attacker simply forwards the message between two byte instances and we have manager middle attack. It's a little bit more tricky to perform the attack from a guest user because as I mentioned before, the access control list of the name byte doesn't allow the guest user to do anything, only authenticated user can create new byte instance or access an open one. So our solution here is by name hijacking. The guest user could create the first instance of the byte and set full access to all user. This way, when the app create its own instance, it doesn't even notice that another user own the name byte and access control of the byte is not as it expect. The rest of the attack is the same as attack by authenticated user that I just described before. The last case study I would like to talk about is a FIDO Utreap security key. FIDO Utreap is standard for second factor authentication and it is supported by many popular services such as Google, Facebook, GitHub. And most security keys implement this standard including UV keys. And even the new Titan security keys that Google introduced few weeks ago also follow this standard. You can see the figure on the right, it is simplified protocol of how the Utreap security key works. So first, the user must register the device with the online service that he wants to enable second factor authentication. Basically, the device generates a public key pair and the service will link the key pair, the public key to the user. And after that, when the user wants to log into the service, the service will send a challenge to the browser and expect to see a response containing the device signature on the challenge. To get the response, the browser will repeat it, we keep sending the challenge to the device until it receives the response. The device, however, it doesn't automatically sign any request it receives. It needs to be activated by touching a button on it. And it only respond to the first request after the touch. So how can we exploit this fiddle security key? So since the security keys is supposed to prevent malicious login, even when the user password has been compromised, we assume here that attacker has obtained the victim's password from some other source and are trying to crack the second factor. The attacker will exploit the factor on the windows and the user, even the one in the background, can access USB HID devices at any time. So here is attack. First, the attacker runs a malicious browser process in his login sessions and sites into the service using the username and password that he has obtained. So malicious browser will receive a challenge from the service. After that, the malicious browser will keep sending the challenge to the device at high rate and the attacker will need to send, it will need to send the challenge to the device at high rate than the initially to meet browser would do to increase the chance of getting the request site. This is easy because Chrome, for example, it sends the challenge to the device every 300 milliseconds. So when the victims sign into any service using the same security key, the victim will touch the button on the device and there's a high probability that the attacker's request will be signed because it is being sent to the device with a very high rate. So user might notice that the first button touch has no effect because it is used by the attacker's request but such minor glitches are normal in computers and typically ignored. We tested the attack on popular services including Facebook and GitHub and we got 100% success rate. So in summary, we have three type of IPC mechanism that are vulnerable to meet my attack, named by network socket, USB, and we have seen real world example of how they are exploited but that's not the only cases that we found. This is a list of the apps that we analyzed and the vulnerabilities that we found. Our focus is on partial managers and other lock-in credentials. We also found for the ability in many other apps, this app follows the client and server architecture. For example, in case of MySQL, on Windows, if the client and the server are on the same computer, the client can connect to the server using name pipe and we were able to perform many middle attack on this channel. So how can meet my attacks can be mitigated? Since the attack are performed by leaving a malicious process running in the background, the most straightforward solution would be to limit the number of users on a computer. Ideally, each computer should be personal to only one user. Also, remote access should be disabled or unlimited to only one user. The meet my attack can also be detected. For example, so developers can compare the owner of the client and the server process and see if they are owned by the same user. It might be more difficult for JavaScript client running in web browser like browser extension because they don't have access to the operating system APIs, so they cannot perform the owner check. In this case, cryptographic protection mechanisms like user-assisted bearing protocol or even standard TLS can be used to protect IPC communication. So the main takeaway message from this presentation is that developers should be aware that IPC is not inherently secure. As we have showed, IPC-based client server architecture may be vulnerable to various type of attacks as in physical networks. And the attacker here is not just malware, but any user or any process including guest account. So if you are interested, you can take a look at our use-based paper. It will be online next week. That's it, thank you.