I have not yet looked into each encryption mode to see how it functions and whether there is some weakness, but it gives greater confidence in using the software. The modes offered are below:
Friday, May 17, 2013
Synergy Adds Encryption
Turns out my previous post is out-dated. When I installed a new operating system, and grabbed a current version of Synergy (1.4.12 for Windows 64-bit), a setting was presented to me:
According to Synergy's own blog, they use AES and are calling it "experimental" encryption.
Monday, May 6, 2013
Keylogger From Captured Synergy Packets
Synergy is a program that allows one keyboard + mouse to control more than one computers' input. Depicted below, as your mouse moves beyond the edge of one computer, it enables input to be directed into the next computer over.
In my curiosity I wondered if the data sent between computers was encrypted. From this I wondered how simple it would be to write a key-logger script that intercepts and records the communication between each computer.
In the above capture, Wireshark was running on my server (10.0.0.128), and I moved the mouse to the client (10.0.0.133) and typed in "testing" As you can see, the "Key Id" is 116. You can use any ASCII table to look up the key value and see that decimal value 116 represents ASCII value "t," the first letter I typed. The previous synergy packets were captures of my mouse movements and clicks. This guarantees us that the data is, in fact, not encrypted, which is our proof of concept. We could stop right here and know that the idea can be implemented, but what's the fun in this whole project if you don't actually have a working key-logger?
In my curiosity I wondered if the data sent between computers was encrypted. From this I wondered how simple it would be to write a key-logger script that intercepts and records the communication between each computer.
Topic: Man-In-The-Middle Capture of Synergy Data
- High Level Abstraction
- How does synergy work?
- How would the key-logging system work?
- Low Level Implementation
- Proof of concept
- The script
- Afterthoughts
- Why this is not a concern
- Mitigation
- Future ideas
1. High Level Abstraction
Referencing the image above, in order for Clients 1 or 2 to know that the mouse is moving or the keyboard is being pressed, the Server must send it that data. The server also must only send the data when appropriate, thus only when the mouse has reached the left or right boundary of the Server. Once this has occurred, Synergy then sends data in the form of mouse coordinates or keystrokes, to which the Synergy client on the receiving machine interprets and causes the machine to register the same action.
Our goal here is to listen on the network for any Synergy traffic, then view and store that traffic into a readable format. Often it may be difficult to achieve a man-in-the-middle when the network on a wire, but if a user was connecting his mouse and keyboard to multiple computers through a WiFi connection, then it would be possible to sniff the communication. Essentially using Synergy on a WiFi network amounts to broadcasting your keystrokes to anyone willing to listen.
2. Low Level Implementation
Before we actually get to coding, we need to make sure the idea will work. To determine whether the data is sent in cleartext, we'll fire up Wireshark and sniff some traffic. You can find information about Wireshark in my Resources page under Software. Wireshark can be running on any machine that uses synergy (client or server), as you can either capture the transmitted data from the server, or capture the received data from the client's NIC.
Referencing the image above, in order for Clients 1 or 2 to know that the mouse is moving or the keyboard is being pressed, the Server must send it that data. The server also must only send the data when appropriate, thus only when the mouse has reached the left or right boundary of the Server. Once this has occurred, Synergy then sends data in the form of mouse coordinates or keystrokes, to which the Synergy client on the receiving machine interprets and causes the machine to register the same action.
Our goal here is to listen on the network for any Synergy traffic, then view and store that traffic into a readable format. Often it may be difficult to achieve a man-in-the-middle when the network on a wire, but if a user was connecting his mouse and keyboard to multiple computers through a WiFi connection, then it would be possible to sniff the communication. Essentially using Synergy on a WiFi network amounts to broadcasting your keystrokes to anyone willing to listen.
2. Low Level Implementation
Before we actually get to coding, we need to make sure the idea will work. To determine whether the data is sent in cleartext, we'll fire up Wireshark and sniff some traffic. You can find information about Wireshark in my Resources page under Software. Wireshark can be running on any machine that uses synergy (client or server), as you can either capture the transmitted data from the server, or capture the received data from the client's NIC.
To implement the logger, we essentially need a simple script that listens to network traffic. We then need to filter that traffic down to only the specific bytes of information that is relevant for our project. Looking at several captures, all Synergy Data packets that are specific to key presses appear to look like the below:
You can see this in the above Wireshark capture (this is the highlighted part). In the above data, I've interpreted it as "block 1 means this is Synergy," "block 2 tells us what key is pressed," while blocks 3 and 4 I'm not concerned with because we have found what we are looking for: the key pressed. In reality, block 1 carries more data than just identifying the packet as the Synergy protocol, it likely includes the fact that the data that follows is a key press, rather than a key release, or a mouse move, or mouse click. All we know is that: all key presses start with block 1. Block 2 is where we are interested. The 0x00 in block 2 becomes 0xef whenever a special key is pressed (such as Shift, Ctrl, Caps Lock, Function keys, etc.) and remains 0x00 whenever a typical alphanumeric key is pressed. All of this tells me to look for synergy packets that match block 1 above, that have 0x00 in the first half of block two, and then to convert the 2nd half of block 2 into ASCII using an ASCII table mentioned earlier.
The above python script is incomplete, but demonstrates the point. Much of it is borrowed from infosec42's blog. Designed to run in Linux, it essentially takes in an interface name as an argument, and listens on that interface. Each packet captured it filters through looking specifically for the above block of data. Before actually using it, I'd clean it up and have it properly output into a file all keystrokes captured. Right now it simply displays "Key caught" with the displayed pressed key.
You can see this in the above Wireshark capture (this is the highlighted part). In the above data, I've interpreted it as "block 1 means this is Synergy," "block 2 tells us what key is pressed," while blocks 3 and 4 I'm not concerned with because we have found what we are looking for: the key pressed. In reality, block 1 carries more data than just identifying the packet as the Synergy protocol, it likely includes the fact that the data that follows is a key press, rather than a key release, or a mouse move, or mouse click. All we know is that: all key presses start with block 1. Block 2 is where we are interested. The 0x00 in block 2 becomes 0xef whenever a special key is pressed (such as Shift, Ctrl, Caps Lock, Function keys, etc.) and remains 0x00 whenever a typical alphanumeric key is pressed. All of this tells me to look for synergy packets that match block 1 above, that have 0x00 in the first half of block two, and then to convert the 2nd half of block 2 into ASCII using an ASCII table mentioned earlier.
The above python script is incomplete, but demonstrates the point. Much of it is borrowed from infosec42's blog. Designed to run in Linux, it essentially takes in an interface name as an argument, and listens on that interface. Each packet captured it filters through looking specifically for the above block of data. Before actually using it, I'd clean it up and have it properly output into a file all keystrokes captured. Right now it simply displays "Key caught" with the displayed pressed key.
3. Afterthoughts
Although it is possible to capture keys sent from Synergy, it really is not a major issue as most computers involved with Synergy are connected directly to the same router (minimizing the path which the packets travel between each other). This would be a concern if the path traveled on the wire is many more hops away, or if there was a spanning port on the router used for monitoring traffic by a third party. Also it would be a problem if two machines are connected and using Synergy wirelessly. If the wifi were open, any sniffer could listen to all the traffic. If it were encrypted, then any person authenticated into the network using a wireless card in promiscuous or monitor mode would be able to capture an interpret the same packets not intended for them.
Although it is possible to capture keys sent from Synergy, it really is not a major issue as most computers involved with Synergy are connected directly to the same router (minimizing the path which the packets travel between each other). This would be a concern if the path traveled on the wire is many more hops away, or if there was a spanning port on the router used for monitoring traffic by a third party. Also it would be a problem if two machines are connected and using Synergy wirelessly. If the wifi were open, any sniffer could listen to all the traffic. If it were encrypted, then any person authenticated into the network using a wireless card in promiscuous or monitor mode would be able to capture an interpret the same packets not intended for them.
A way to mitigate this worry completely is to encrypt the data. While Synergy has no option of encrypting it, you can add your own layer of encryption by using OpenSSH. Referencing a SourceForge page, you first install the OpenSSH server on the same computer as the synergy server, and OpenSSH client on each Synergy client. Specific instructions can be found in the SourceForge link.
This whole session has now brought new curiosity: what if I craft my own packets from a third-party computer and send them to the client listening for Synergy packets? Would I effectively have control of the mouse and keyboard of this client? If so, I could then send a payload of synchronized packets that starts a command and shovels a shell for a more persistent connection. Synergy appears to authenticate only on IP addresses that can be easily spoofed (from the settings, you input a computer name that you want as your Synergy server, and that appears to be the only form of authentication as shown below).
I plan on having my next post be on trying to exploit a computer running Synergy Client using crafted Synergy packets.
-Namrack
This whole session has now brought new curiosity: what if I craft my own packets from a third-party computer and send them to the client listening for Synergy packets? Would I effectively have control of the mouse and keyboard of this client? If so, I could then send a payload of synchronized packets that starts a command and shovels a shell for a more persistent connection. Synergy appears to authenticate only on IP addresses that can be easily spoofed (from the settings, you input a computer name that you want as your Synergy server, and that appears to be the only form of authentication as shown below).
I plan on having my next post be on trying to exploit a computer running Synergy Client using crafted Synergy packets.
-Namrack
Thursday, April 25, 2013
Reasons and Philosophy
- Why I created this blog.
- My Experience.
- My Philosophy
After reading a blog entry about getting TrueCrypt passphrases from information in volatile memory, I realized that there is a lot I do not know or understand about computers. I also realized I may not be alone in this category. I figure what better way to help myself as well as others in overcoming this challenge is to document my learning experiences from here on.
2. My Experience:
I grew up using Windows. From 95 to XP to 7, all information about the internals of the machine were masked to me. Recently I dove into Linux (starting with Slackware, then switching into Ubuntu for a more gentle entry). After discovering how misled I was about the simplicities of a computer, (misled as in "click here and Windows' magic will take care of the rest") I simply became curious and wanted to learn everything about everything about computers.
3. My Philosophy:
I am going to approach each blog entry with zero assumptions: and my goal is to teach each new subject I recently discover. I figure the best way to learn something is to gain the confidence to teach it. In order to teach it effectively, I am going to take the approach of initializing with a high-level abstract concept overview, and then step down the abstraction as I go into more concrete hands-on implementation examples. I believe it is very easy to understand the concepts, but difficult to bridge the gap between an abstract understanding and a concrete implementation (essentially answering the question "I understand how it works, but where do I even begin to actually do it?" This blog is going to be more security focused, but concepts will include anything that can relate to a computer and will have few limitations.
Wednesday, April 24, 2013
Hello World.
This is my first post using any blogging utility, and is a test to see the look and feel after its published.
Click here to show the overlay1
Click here to show the overlay2
Click here to open new window 2
Click here to show the overlay1
Click here to show the overlay2
Click here to open new window 2
Subscribe to:
Posts (Atom)