Synergy is a type of mouse an keyboard sharing software. When configured, moving your mouse off the screen will allow you to control another system that is also set up with Synergy. Below is a YouTube video from Synergy on how it works:

The way this works is one host acts as the Synergy server, and the other hosts act as Synergy clients. The clients initiate connections to the server to allow that server to send commands to them, such as moving the mouse, using the keyboard, or accessing the clipboard.

Synergy has two main pricing tiers, Basic, and Pro. They are almost identical, but the Pro version supports SSL encryption.  Symless, the company that develops the Synergy acknowledges the risk of using the un-encrypted version, and suggests to either buy the Pro version, or encapsulate the Synergy traffic within an SSH tunnel.

I was curious about the risk posed by using this software without any additional steps taken to secure the communication channel.  My research didn’t turn up much, only one security researcher discussing a crypto fail in an older version of Pro, and forum threads of a few cautious power users.

The first thing most warned about is eavesdropping on keystrokes, which often times will contain sensitive information to include passwords.  Assuming you have Man-In-The-Middle between a client and server, are on a network using a hub, receiving traffic from a span port, or otherwise have a pcap of the traffic, extracting keystrokes is quite simple.  Here is a few lines of python that will do just that:

You will need to install scapy to run this.  The code relatively simple, it will begin sniffing on all interfaces for TCP traffic going either to or from port 24800, and each packet that has the string “DKDN” identified a key-down event, meaning a key was pressed to the down position. Assuming they are typing in English, the 9th byte will contain an ASCII character.  This is a basic example and does not address any non-ASCII or non-printable characters, but works as a general proof of concept.

Keystroke monitoring is interesting by itself, but I was curious if there was more that could be done.  Having previously analyzed other protocols such as VNC and HippoConnect, injecting keystrokes onto the target to execute a payload seemed like an interesting type of attack.

After spending some time in Wireshark analyzing the communication between the client and sever, I found a few items of note:

  • The client initiates the communication with the server
  • Commands are sent from the server to the client

This led me to conclude that by impersonating a Synergy server and enticing a client to connect to it, I could compromise the client.

Synergy comes with the ability to perform automatic configuration of a client and server.  It does this by using Bonjour.  To quote the wiki:

Bonjour is one application of the ZeroConf protocol, which was originally designed for things like printers and scanners to be automatically found on a network when a new computer connects. In the old days, you would have to dig into the printer’s settings or print a label on the front of the printer to find its IP address and add it to your setup manually. This protocol was developed to make this process easier. It was also designed to be used with anything which needed to have a client find a server, which is the case with Synergy. We use ZeroConf (Bonjour) to allow Synergy Clients to automatically find Synergy Servers.

If an attacker could advertise their rogue Synergy server via Bonjour, a client with the “Auto config” option checked could connect to it and our rogue server could begin injecting malicious keystrokes to the target.  The caveats to this attack succeeding is that the victim client must not be currently connected to any other Synergy server, and that our server was registered on the top of the MDNS cache.

I developed a python script that will impersonate a Synergy server that I’ve named “Dissonance” and it’s available on GitHub.

I’ve recorded a video of this attack in action.  I find it’s best to watch in at least 1080p to capture all the details. (Yes, I know “rouge” should be “rogue”)

Here is a breakdown of what happened:

  • The attacker ran the Dissonance python script. This opened up port 24800 and sent out Bonjour advertisements
  • The Synergy client clicked the “Auto-config” option.  It used Bonjour to identify the attacker system as a Synergy server
  • It initiated a connection on TCP port 24800 to the attacker
  • The attack script negotiated the connection and began sending keystrokes to the client which opened a command prompt and typed in a payload
  • The payload was a powershell command that was Base64 encoded which would retrieve and execute a Powershell Empire stager
  • The client initiates a connection with the Empire server and the Empire server now has control over the client system

This attack works well, but most likely any Synergy clients you come across will already be connected to a Synergy server.  The next thing to try is to see if it is possible to hijack an existing relationship.  To hijack a client we would have to replace the real server with our own without the client being aware. Fortunately for the attacker, a Synergy client that loses its connection to the server will automatically try to reconnect.

To facilitate this attack, a little bit of recon must be done.  Synergy servers are possible to find via a typical Nmap scan.  Nmap has a fingerprint for Synergy servers and you should see something like this:

Another way to identify both clients and servers is by using Bonjour.  Even if you don’t use auto config, Bonjour is installed as part of the set-up process, unless declined.  Both clients and servers register themselves via MDNS when the application is launched.

Here is a video of this attack in action, and it has more moving parts than the last:

Here is the a run-down of what happens in the video:

  • The Synergy client has an active connection with the Synergy server
  • The attacker uses Dissonance to identify the IP addresses of the client and server via Bonjour
  • The attacker assumes the IP of the real Synergy server
  • arpspoof is used to send ARP reply to the Synergy client to update the victims ARP table to identify the attacker as having the MAC address for the IP that belonged to the legitimate Synergy server
  • The client and server lose their connection.  Th client automatically makes attempts to re-establish the connection
  • The attacker starts Dissonance
  • The client connects to the rogue server and begins accepting commands
  • As before, an Empire stager is executed on the client and the client initiates a connection to the Empire server

The next question is if this is possible with the Pro version.  The answer is: Not without user interaction.  When using the Pro version, when a client first initiates a connection to the Server it asks the user to validate the fingerprint.  This is the prompt seen from the client:

If the IP address is hijacked in the attack seen above, such a warning would present itself once the client connected to the rogue server.  If the client were to ignore the content and just click “Yes” this type of attack could still be achieved.  If the user followed the instructions they would certainly click no, but in some environments where users are accustomed to ignoring SSL/TLS certificate warnings, this may be possible.