SlideShare a Scribd company logo

Last mile authentication problem: Exploiting the missing link in end-to-end secure communication

•
•
Priyanka Aash
Priyanka Aash

"With ""Trust none over the Internet"" mindset, securing all communication between a client and a server with protocols such as TLS has become a common practice. However, while the communication over Internet is routinely secured, there is still an area where such security awareness is not seen: inside individual computers, where adversaries are often not expected. This talk discusses the security of various inter-process communication (IPC) mechanisms that local processes and applications use to interact with each other. In particular, we show IPC-related vulnerabilities that allow a non-privileged process to steal passwords stored in popular password managers and even second factors from hardware tokens. With passwords being the primary way of authentication, the insecurity of this ""last mile"" causes the security of the rest of the communication strands to be obsolete. The vulnerabilities that we demonstrate can be exploited on multi-user computers that may have processes of multiple users running at the same time. The attacker is a non-privileged user trying to steal sensitive information from other users. Such computers can be found in enterprises with centralized access control that gives multiple users access to the same host. Computers with guest accounts and shared computers at home are similarly vulnerable."

1 of 42
Download to read offline
Last mile authentication problem Exploiting the missing link in end-to-end secure communication
Our team Thanh Bui Doctoral Candidate Aalto University Finland Sid Rao Doctoral Candidate Aalto University Finland Dr. Markku Antikainen Post-doc researcher University of Helsinki Finland Prof. Tuomas Aura Professor Aalto University Finland 2
Traditional network threat model ● Server and user device are trusted ● Software is trusted ● Untrusted network: ○ “man in the middle” ● E.g. web server and web browser ● Crypto (TLS and web PKI) to protect communication 3 Server User device Client
● Not all communication goes over the traditional network ○ Inter Process Communication ● Multiple untrusted services run inside the user device We try to understand security of communication inside the computer Communication inside a computer - IPC 4 User device Frontend process Backend process
Man in the Machine (MitMa) ● MitMa attacker: Another user at home or at work, including guest ● Attacker goal: Impersonate communication endpoints in IPC ● Attack method: ○ Runs a malicious process in the background (no privilege escalation required) ○ Fast user switching, remote access (e.g. ssh, remote desktop) 5 Alice’s session Frontend process Backend process Guest’s session Malware
This talk ● We exploit “last mile communication” inside the computer ● Structure ○ IPC and attack vectors ○ Case studies ■ Password managers ■ USB security tokens ○ Mitigation ○ Conclusion 6
This talk ● We exploit “last mile communication” inside the computer ● Structure ○ IPC and attack vectors ○ Case studies ■ Password managers ■ USB security tokens ○ Mitigation ○ Conclusion 7 Credentials and second authentication factors can be compromised from inside the computer zz
Inter Process Communication 8
IPC methods ● File system ● Signal and semaphore ● Network socket and Unix domain socket ● Message queue ● Anonymous pipe and named pipe ● Shared memory ● Clipboard ● Remote Procedure Call (RPC) ● USB (though not strictly an IPC method) ● ... 9
Network sockets ● Mainly for communication across network but used for IPC as well ○ Over loopback interface: 127.0.0.0/8 or ::1/128 ● Server listens on a specified port and waits for incoming client requests ○ Only a single process can bind to a port at a time ○ Any process regardless of its owner can listen on ports > 1024 ● Local processes can connect to the server as clients if the port is known ● No built-in access control 10
Network sockets - Attack vectors (1) Client impersonation ● Any local process can connect to any server port on localhost ● If server accepts only one client, connects before the legitimate client Server impersonation ● Bind to the port before the legitimate server does 11
Network sockets - Attack vectors (1) Client impersonation ● Any local process can connect to any server port on localhost ● If server accepts only one client, connects before the legitimate client Server impersonation ● Bind to the port before the legitimate server does Legitimate and malicious servers cannot bind to the same port at the same time Man-in-the-Middle? 12
Network sockets - Attack vectors (2) Man-in-the-Middle attack ● Port agility ○ If primary port is taken, the server might failover to another port from a predefined list ○ MitMa attacker can ■ Listen on the primary port to receive client connection, and ■ Connect himself to the legitimate server on the secondary port 13
Network sockets - Attack vectors (2) Man-in-the-Middle attack ● Port agility ○ If primary port is taken, the server might failover to another port from a predefined list ○ MitMa attacker can ■ Listen on the primary port to receive client connection, and ■ Connect himself to the legitimate server on the secondary port ● No port agility ○ Replay messages by alternating between the client and server roles ○ Rate of messages passing through the attacker will be slow but might still be practical 14
Windows named pipe 15 ● Similar client-server architecture as network socket’s, but multiple processes can simultaneously act as servers ○ A named pipe can have multiple instances that share the same name ○ Each instance connects exactly one pipe server and one pipe client ○ New pipe clients connected to the pipe servers in round-robin order ● Named pipes placed in a special path .pipe ○ Every user (including guest) has access to the path ● Have built-in access control!
Windows named pipe - Access control 16 ● If a named pipe doesn’t exist, any user can create it (including guest) ● If it exists, only users with FILE_CREATE_PIPE_INSTANCE permission can create new instances ● The first instance of the named pipe decides the maximum instances and security descriptor (DACL) ○ Default DACL: ■ READ access to everyone ■ FULL access to the creator and admins
Windows named pipe - Attack vectors Client impersonation ● Any process can connect to any open pipe instance but subject to access control check Server impersonation ● Pipe name hijacking: create the first instance to control the pipe’s DACL and maximum instances ○ Set DACL to allow everyone to create new instances Client + Server impersonation = Man-in-the-middle 17
USB Human Interface Devices (USB HID) ● E.g. keyboards, pointing devices, hardware security tokens ● On Linux and macOS, ○ USB HIDs accessed from only current active user session ● On Windows, ○ USB HIDs accessed from any user session, including those in the background ○ Security of the devices depends on application-level security mechanism implemented in the hardware or software 18
Case studies 19
● Native (desktop) app manages the password vault ○ Password vault encrypted with a key derived from a master password ● Browser extension creates and stores passwords, and enters them into login pages ● Browser extension and native app communicate via IPC Password managers 20 User device Web browser Web page Native app Browser extension
● Native app runs a HTTP/WebSocket server on a predefined port ● Browser extension connects as a client to the server ● Threats: ○ Browser extension is sandboxed → unable to perform most checks on the server process Password managers w/ Network socket 21 Web browser Web page Browser extension 8080 Network socket Native app
Case study - Dashlane ● Dashlane app runs a WebSocket server on port 11456 ● Communication: ○ Messages encrypted with a key derived from hard-coded constant ○ Server verifies client by checking: ■ Browser extension ID in Origin header of each message ■ Code signature of the client process to make sure it is a known browser ■ Client process owned by same user as the server’s ○ Client does NOT verify server 22
Case study - Dashlane ● Dashlane app runs a WebSocket server on port 11456 ● Communication: ○ Messages encrypted with a key derived from hard-coded constant ○ Server verifies client by checking: ■ Browser extension ID in Origin header of each message ■ Code signature of the client process to make sure it is a known browser ■ Client process owned by same user as the server’s ○ Client does NOT verify server 23 Client impersonation Server impersonation
Server impersonation on Dashlane (1) Attack steps: 1. Extract hard-coded encryption key from the browser extension’s code 2. Run WebSocket server on port 11456 before the benign server does ○ Benign server silently failovers to another port 3. Use the hard-coded key to communicate with the browser extension 24 Web browser Web page Browser extension 11456 MitMa attacker Network socket Dashlane app11457
Server impersonation on Dashlane (2) Results: ● Dashlane browser extension collects and sends DOM elements from web pages to app for analysis → Attacker obtains personal data, such as emails and messages, from web pages ● Server can instruct the browser extension to collect web-form data and send to it → Attacker obtains any text typed by the user, including credentials 25
Case study - 1Password ● 1Password app runs a WebSocket server on port 6263 ● Communication: ○ Server verifies client in the same way as Dashlane does ○ In the first communication, server and client run a self-made protocol to agree on a shared encryption key 26 1. C → S: “hello” 2. C ← S: code (random 6-digit string) 3. C → S: hmac_key 4. Both extension and app displays the code 5. User confirms to the app if they match 6. C ← S: “authRegistered” 7. C → S: nonceC 8. C ← S: nonceS , mS =HMAC(hmac_key, nonceS ||nonceC ) 9. C → S: mC =HMAC(hmac_key, mS ) 10. C ← S: “welcome” 11. Both sides derive encryption key K=HMAC(hmac_key, ms ||mC ||”encryption”)
Case study - 1Password ● 1Password app runs a WebSocket server on port 6263 ● Communication: ○ Server verifies client in the same way as Dashlane does ○ In the first communication, server and client run a self-made protocol to agree on a shared encryption key 27 1. C → S: “hello” 2. C ← S: code (random 6-digit string) 3. C → S: hmac_key 4. Both extension and app displays the code 5. User confirms to the app if they match 6. C ← S: “authRegistered” 7. C → S: nonceC 8. C ← S: nonceS , mS =HMAC(hmac_key, nonceS ||nonceC ) 9. C → S: mC =HMAC(hmac_key, mS ) 10. C ← S: “welcome” 11. Both sides derive encryption key K=HMAC(hmac_key, ms ||mC ||”encryption”) Client impersonation Server impersonation
MitMa on 1Password (Demo)
Native messaging 29 ● Browser’s built-in method for communicating between browser extension and native code ● App registers with the browser: ○ an executable, called Native Messaging Host (NMH), and ○ a configuration file specifying which browser extensions have access to the NMH ● Browser starts the NMH in a child process and lets the browser extension communicate with it
Native messaging 30 ● Browser’s built-in method for communicating between browser extension and native code ● App registers with the browser: ○ an executable, called Native Messaging Host (NMH), and ○ a configuration file specifying which browser extensions have access to the NMH ● Browser starts the NMH in a child process and lets the browser extension communicate with it Native messaging is immune to MitMa attacks
Password managers w/ Native messaging 31 ● Password manager app registers a NMH with the browser and allows only its browser extension to communicate with the NMH ● However, NMH and the native app are still two separate processes → they use IPC to communicate with each other Web browser Web page Browser extension Native app App-specific IPC Native messaging host Native messaging
Case study - Password Boss ● On Windows, named pipe used for IPC between NMH and the native app ● When the app starts, it creates a named pipe with: ○ Fixed name ○ Maximum instance = 50 ○ DACL allowing all authenticated users to have FULL access ● NMH connects to the named pipe as a pipe client and forwards messages between browser extension and native app ● All messages are sent in plaintext 32
Case study - Password Boss ● On Windows, named pipe used for IPC between NMH and the native app ● When the app starts, it creates a named pipe with: ○ Fixed name ○ Maximum instance = 50 ○ DACL allowing all authenticated users to have FULL access ● NMH connects to the named pipe as a pipe client and forwards messages between browser extension and native app ● All messages are sent in plaintext 33 Man-in-the-Middle
Man-in-the-Middle on Password Boss (1) By authenticated user: 1. Connects as a client to the app’s named pipe instance 2. Creates another instance of the named pipe and waits for the NMH 3. NMH connects to the attacker’s instance because it is the only open instance 4. Forwards messages between the two pipe instances 34 AppAttacker Client Server 1st inst. NMH Attacker2nd inst.
Man-in-the-Middle on Password Boss (2) By guest user: ● Guest cannot access the app’s pipe instance or create a new one ● Solution: Pipe name hijacking ○ Create the first instance and set a FULL access DACL to all users ● Rest is same as the attack by authenticated user 35 AppAttacker Client Server 2nd inst. NMH Attacker3rd inst. Attacker Attacker1st inst.
Case study - FIDO U2F security key ● 2nd authentication factor based on public key crypto and a USB device ● Challenge-response protocol ○ Browser keeps sending the challenge from the server to the device until it receives response (every 300 ms on Chrome) ○ User activates the device by touching a button on it ○ The device responds to only the first request after the touch 36 Browser Security key Server username, password Verify password challenge challenge User touches button response response Verify response
Unauthorized access of FIDO U2F key 37 Reminder: On Windows, USB HIDs can be accessed from any user session Assumption: Attacker has obtained the 1st authentication factor Attack steps: 1. Signs in to the service in the background using the 1st factor 2. Sends the challenge from the service to the device at a high rate 3. Victim (in the foreground) signs in to ANY service using the same security key and touches the button on the device ○ The first button touch had no effect, but such minor glitches are typically ignored 4. The attacker’s request gets signed instead of the victim’s with high probability, and then the attacker obtains the 2nd factor
MitMa on FIDO U2F Key (Demo)
Discovered vulnerabilities 39 Application IPC Channel Attacks Password managers Roboform Y N - Network socket Client imp. Dashlane Y Y - Network socket Server imp. 1Password Y N - Network socket Server imp. F-Secure Key Y Y - Network socket Client imp. Server imp. Password Boss N Y - Named pipe Man-in-the-Middle Sticky Password Y N - Network socket Client imp. Server imp. Hardware tokens FIDO U2F Key N Y N USB Unauthorized access DigiSign Y Y Y Network socket Client imp. Others Blizzard Y Y - Network socket Client imp. Transmission Y Y Y Network socket Client imp. Spotify Y Y Y Network socket Client imp. MySQL N Y N Named pipe Man-in-the-Middle Keybase N Y N Named pipe Server imp. macOS Windows Linux
Mitigation ● Spatial and temporal separation of users ○ Limit the number of users that can access a computer ○ Disable remote access, such as SSH and Remote desktop ● Attack detection easier in IPC than in network ○ Compare owner of client and server processes ○ Query client/server binary ● Cryptographic protection ○ User-assisted pairing vs TLS and PKI ○ Avoid self-made crypto! 40
Conclusion Software developers beware, IPC is not inherently secure! ● Unprivileged user or process can attack IPC of another user on the same computer ● Traditional network security threats exist also in IPC ● We are doing a more exhaustive survey ○ Contribute, if you are interested! 41
Contact Thanh Bui: thanh.bui@aalto.fi Siddharth Rao: siddharth.rao@aalto.fi Markku Antikainen: markku.antikainen@helsinki.fi Tuomas Aura: tuomas.aura@aalto.fi Read more ”Man-in-the-Machine: Exploiting ill-secured communication inside the computer”, USENIX Security 2018 42 Thank you!

More Related Content

Last mile authentication problem: Exploiting the missing link in end-to-end secure communication

  • 1. Last mile authentication problem Exploiting the missing link in end-to-end secure communication
  • 2. Our team Thanh Bui Doctoral Candidate Aalto University Finland Sid Rao Doctoral Candidate Aalto University Finland Dr. Markku Antikainen Post-doc researcher University of Helsinki Finland Prof. Tuomas Aura Professor Aalto University Finland 2
  • 3. Traditional network threat model ● Server and user device are trusted ● Software is trusted ● Untrusted network: ○ “man in the middle” ● E.g. web server and web browser ● Crypto (TLS and web PKI) to protect communication 3 Server User device Client
  • 4. ● Not all communication goes over the traditional network ○ Inter Process Communication ● Multiple untrusted services run inside the user device We try to understand security of communication inside the computer Communication inside a computer - IPC 4 User device Frontend process Backend process
  • 5. Man in the Machine (MitMa) ● MitMa attacker: Another user at home or at work, including guest ● Attacker goal: Impersonate communication endpoints in IPC ● Attack method: ○ Runs a malicious process in the background (no privilege escalation required) ○ Fast user switching, remote access (e.g. ssh, remote desktop) 5 Alice’s session Frontend process Backend process Guest’s session Malware
  • 6. This talk ● We exploit “last mile communication” inside the computer ● Structure ○ IPC and attack vectors ○ Case studies ■ Password managers ■ USB security tokens ○ Mitigation ○ Conclusion 6
  • 7. This talk ● We exploit “last mile communication” inside the computer ● Structure ○ IPC and attack vectors ○ Case studies ■ Password managers ■ USB security tokens ○ Mitigation ○ Conclusion 7 Credentials and second authentication factors can be compromised from inside the computer zz
  • 9. IPC methods ● File system ● Signal and semaphore ● Network socket and Unix domain socket ● Message queue ● Anonymous pipe and named pipe ● Shared memory ● Clipboard ● Remote Procedure Call (RPC) ● USB (though not strictly an IPC method) ● ... 9
  • 10. Network sockets ● Mainly for communication across network but used for IPC as well ○ Over loopback interface: 127.0.0.0/8 or ::1/128 ● Server listens on a specified port and waits for incoming client requests ○ Only a single process can bind to a port at a time ○ Any process regardless of its owner can listen on ports > 1024 ● Local processes can connect to the server as clients if the port is known ● No built-in access control 10
  • 11. Network sockets - Attack vectors (1) Client impersonation ● Any local process can connect to any server port on localhost ● If server accepts only one client, connects before the legitimate client Server impersonation ● Bind to the port before the legitimate server does 11
  • 12. Network sockets - Attack vectors (1) Client impersonation ● Any local process can connect to any server port on localhost ● If server accepts only one client, connects before the legitimate client Server impersonation ● Bind to the port before the legitimate server does Legitimate and malicious servers cannot bind to the same port at the same time Man-in-the-Middle? 12
  • 13. Network sockets - Attack vectors (2) Man-in-the-Middle attack ● Port agility ○ If primary port is taken, the server might failover to another port from a predefined list ○ MitMa attacker can ■ Listen on the primary port to receive client connection, and ■ Connect himself to the legitimate server on the secondary port 13
  • 14. Network sockets - Attack vectors (2) Man-in-the-Middle attack ● Port agility ○ If primary port is taken, the server might failover to another port from a predefined list ○ MitMa attacker can ■ Listen on the primary port to receive client connection, and ■ Connect himself to the legitimate server on the secondary port ● No port agility ○ Replay messages by alternating between the client and server roles ○ Rate of messages passing through the attacker will be slow but might still be practical 14
  • 15. Windows named pipe 15 ● Similar client-server architecture as network socket’s, but multiple processes can simultaneously act as servers ○ A named pipe can have multiple instances that share the same name ○ Each instance connects exactly one pipe server and one pipe client ○ New pipe clients connected to the pipe servers in round-robin order ● Named pipes placed in a special path .pipe ○ Every user (including guest) has access to the path ● Have built-in access control!
  • 16. Windows named pipe - Access control 16 ● If a named pipe doesn’t exist, any user can create it (including guest) ● If it exists, only users with FILE_CREATE_PIPE_INSTANCE permission can create new instances ● The first instance of the named pipe decides the maximum instances and security descriptor (DACL) ○ Default DACL: ■ READ access to everyone ■ FULL access to the creator and admins
  • 17. Windows named pipe - Attack vectors Client impersonation ● Any process can connect to any open pipe instance but subject to access control check Server impersonation ● Pipe name hijacking: create the first instance to control the pipe’s DACL and maximum instances ○ Set DACL to allow everyone to create new instances Client + Server impersonation = Man-in-the-middle 17
  • 18. USB Human Interface Devices (USB HID) ● E.g. keyboards, pointing devices, hardware security tokens ● On Linux and macOS, ○ USB HIDs accessed from only current active user session ● On Windows, ○ USB HIDs accessed from any user session, including those in the background ○ Security of the devices depends on application-level security mechanism implemented in the hardware or software 18
  • 20. ● Native (desktop) app manages the password vault ○ Password vault encrypted with a key derived from a master password ● Browser extension creates and stores passwords, and enters them into login pages ● Browser extension and native app communicate via IPC Password managers 20 User device Web browser Web page Native app Browser extension
  • 21. ● Native app runs a HTTP/WebSocket server on a predefined port ● Browser extension connects as a client to the server ● Threats: ○ Browser extension is sandboxed → unable to perform most checks on the server process Password managers w/ Network socket 21 Web browser Web page Browser extension 8080 Network socket Native app
  • 22. Case study - Dashlane ● Dashlane app runs a WebSocket server on port 11456 ● Communication: ○ Messages encrypted with a key derived from hard-coded constant ○ Server verifies client by checking: ■ Browser extension ID in Origin header of each message ■ Code signature of the client process to make sure it is a known browser ■ Client process owned by same user as the server’s ○ Client does NOT verify server 22
  • 23. Case study - Dashlane ● Dashlane app runs a WebSocket server on port 11456 ● Communication: ○ Messages encrypted with a key derived from hard-coded constant ○ Server verifies client by checking: ■ Browser extension ID in Origin header of each message ■ Code signature of the client process to make sure it is a known browser ■ Client process owned by same user as the server’s ○ Client does NOT verify server 23 Client impersonation Server impersonation
  • 24. Server impersonation on Dashlane (1) Attack steps: 1. Extract hard-coded encryption key from the browser extension’s code 2. Run WebSocket server on port 11456 before the benign server does ○ Benign server silently failovers to another port 3. Use the hard-coded key to communicate with the browser extension 24 Web browser Web page Browser extension 11456 MitMa attacker Network socket Dashlane app11457
  • 25. Server impersonation on Dashlane (2) Results: ● Dashlane browser extension collects and sends DOM elements from web pages to app for analysis → Attacker obtains personal data, such as emails and messages, from web pages ● Server can instruct the browser extension to collect web-form data and send to it → Attacker obtains any text typed by the user, including credentials 25
  • 26. Case study - 1Password ● 1Password app runs a WebSocket server on port 6263 ● Communication: ○ Server verifies client in the same way as Dashlane does ○ In the first communication, server and client run a self-made protocol to agree on a shared encryption key 26 1. C → S: “hello” 2. C ← S: code (random 6-digit string) 3. C → S: hmac_key 4. Both extension and app displays the code 5. User confirms to the app if they match 6. C ← S: “authRegistered” 7. C → S: nonceC 8. C ← S: nonceS , mS =HMAC(hmac_key, nonceS ||nonceC ) 9. C → S: mC =HMAC(hmac_key, mS ) 10. C ← S: “welcome” 11. Both sides derive encryption key K=HMAC(hmac_key, ms ||mC ||”encryption”)
  • 27. Case study - 1Password ● 1Password app runs a WebSocket server on port 6263 ● Communication: ○ Server verifies client in the same way as Dashlane does ○ In the first communication, server and client run a self-made protocol to agree on a shared encryption key 27 1. C → S: “hello” 2. C ← S: code (random 6-digit string) 3. C → S: hmac_key 4. Both extension and app displays the code 5. User confirms to the app if they match 6. C ← S: “authRegistered” 7. C → S: nonceC 8. C ← S: nonceS , mS =HMAC(hmac_key, nonceS ||nonceC ) 9. C → S: mC =HMAC(hmac_key, mS ) 10. C ← S: “welcome” 11. Both sides derive encryption key K=HMAC(hmac_key, ms ||mC ||”encryption”) Client impersonation Server impersonation
  • 29. Native messaging 29 ● Browser’s built-in method for communicating between browser extension and native code ● App registers with the browser: ○ an executable, called Native Messaging Host (NMH), and ○ a configuration file specifying which browser extensions have access to the NMH ● Browser starts the NMH in a child process and lets the browser extension communicate with it
  • 30. Native messaging 30 ● Browser’s built-in method for communicating between browser extension and native code ● App registers with the browser: ○ an executable, called Native Messaging Host (NMH), and ○ a configuration file specifying which browser extensions have access to the NMH ● Browser starts the NMH in a child process and lets the browser extension communicate with it Native messaging is immune to MitMa attacks
  • 31. Password managers w/ Native messaging 31 ● Password manager app registers a NMH with the browser and allows only its browser extension to communicate with the NMH ● However, NMH and the native app are still two separate processes → they use IPC to communicate with each other Web browser Web page Browser extension Native app App-specific IPC Native messaging host Native messaging
  • 32. Case study - Password Boss ● On Windows, named pipe used for IPC between NMH and the native app ● When the app starts, it creates a named pipe with: ○ Fixed name ○ Maximum instance = 50 ○ DACL allowing all authenticated users to have FULL access ● NMH connects to the named pipe as a pipe client and forwards messages between browser extension and native app ● All messages are sent in plaintext 32
  • 33. Case study - Password Boss ● On Windows, named pipe used for IPC between NMH and the native app ● When the app starts, it creates a named pipe with: ○ Fixed name ○ Maximum instance = 50 ○ DACL allowing all authenticated users to have FULL access ● NMH connects to the named pipe as a pipe client and forwards messages between browser extension and native app ● All messages are sent in plaintext 33 Man-in-the-Middle
  • 34. Man-in-the-Middle on Password Boss (1) By authenticated user: 1. Connects as a client to the app’s named pipe instance 2. Creates another instance of the named pipe and waits for the NMH 3. NMH connects to the attacker’s instance because it is the only open instance 4. Forwards messages between the two pipe instances 34 AppAttacker Client Server 1st inst. NMH Attacker2nd inst.
  • 35. Man-in-the-Middle on Password Boss (2) By guest user: ● Guest cannot access the app’s pipe instance or create a new one ● Solution: Pipe name hijacking ○ Create the first instance and set a FULL access DACL to all users ● Rest is same as the attack by authenticated user 35 AppAttacker Client Server 2nd inst. NMH Attacker3rd inst. Attacker Attacker1st inst.
  • 36. Case study - FIDO U2F security key ● 2nd authentication factor based on public key crypto and a USB device ● Challenge-response protocol ○ Browser keeps sending the challenge from the server to the device until it receives response (every 300 ms on Chrome) ○ User activates the device by touching a button on it ○ The device responds to only the first request after the touch 36 Browser Security key Server username, password Verify password challenge challenge User touches button response response Verify response
  • 37. Unauthorized access of FIDO U2F key 37 Reminder: On Windows, USB HIDs can be accessed from any user session Assumption: Attacker has obtained the 1st authentication factor Attack steps: 1. Signs in to the service in the background using the 1st factor 2. Sends the challenge from the service to the device at a high rate 3. Victim (in the foreground) signs in to ANY service using the same security key and touches the button on the device ○ The first button touch had no effect, but such minor glitches are typically ignored 4. The attacker’s request gets signed instead of the victim’s with high probability, and then the attacker obtains the 2nd factor
  • 39. Discovered vulnerabilities 39 Application IPC Channel Attacks Password managers Roboform Y N - Network socket Client imp. Dashlane Y Y - Network socket Server imp. 1Password Y N - Network socket Server imp. F-Secure Key Y Y - Network socket Client imp. Server imp. Password Boss N Y - Named pipe Man-in-the-Middle Sticky Password Y N - Network socket Client imp. Server imp. Hardware tokens FIDO U2F Key N Y N USB Unauthorized access DigiSign Y Y Y Network socket Client imp. Others Blizzard Y Y - Network socket Client imp. Transmission Y Y Y Network socket Client imp. Spotify Y Y Y Network socket Client imp. MySQL N Y N Named pipe Man-in-the-Middle Keybase N Y N Named pipe Server imp. macOS Windows Linux
  • 40. Mitigation ● Spatial and temporal separation of users ○ Limit the number of users that can access a computer ○ Disable remote access, such as SSH and Remote desktop ● Attack detection easier in IPC than in network ○ Compare owner of client and server processes ○ Query client/server binary ● Cryptographic protection ○ User-assisted pairing vs TLS and PKI ○ Avoid self-made crypto! 40
  • 41. Conclusion Software developers beware, IPC is not inherently secure! ● Unprivileged user or process can attack IPC of another user on the same computer ● Traditional network security threats exist also in IPC ● We are doing a more exhaustive survey ○ Contribute, if you are interested! 41
  • 42. Contact Thanh Bui: thanh.bui@aalto.fi Siddharth Rao: siddharth.rao@aalto.fi Markku Antikainen: markku.antikainen@helsinki.fi Tuomas Aura: tuomas.aura@aalto.fi Read more ”Man-in-the-Machine: Exploiting ill-secured communication inside the computer”, USENIX Security 2018 42 Thank you!