Applications that are in use on Macs often times are under less scrutiny for security compared to their Windows alternatives. When researching popular apps in use on OS X I found an app on the iPhone called HippoRemote. It appears to be quite popular, with a combined 7,558 reviews on the iTunes store for both the LITE and Pro versions. It has also been featured heavily on tech blogs such as Mashable, Lifehacker, Cult of Mac, Macworld, and many more. What this software does is that it allows you to use your phone as a wireless trackpad and keyboard. A cursory review of their website will show you that this is actually cross-platform, it is available for Mac, Windows, and Linux. The Pro edition boasts various features such as a Login Manager that allows you to “Securely store your passwords and sign into websites with a single tap.”
Before going into the Mac version, I’m going to spend some time on the Windows version. The software was downloaded from the website and the 7-zip self extracting archive utility was ran. The extracted application is called “HippoVNC” and by checking the about menu you can see that HippoVNC is forked off of UltraVNC. For those of you who have been doing security a while, you may already be aware of some of the security concerns with VNC. This first half of the article addresses those.
VNC typically will store the VNC password in either the registry or an .ini configuration file. Since HippoVNC is based off of UltraVNC, it stores it in a config file. This is important, because the confidentiality of this password is now dependent upon the NTFS permissions on the host. In some cases this could be fine – however if the HippoVNC software was extracted into an area accessible to other users, the config file could be read by others. The password in the config file is encrypted – but to little affect. The password is only encrypted with DES – a weak and deprecated algorithm. Even with encryption it is effectively plaintext, as the key by which all VNC passwords are encrypted is within the VNC source code.
{23, 82, 107, 6, 35, 78, 88, 7}
The other issues with VNC become more apparent when you analyze the packets on the wire. Below is a screenshot when performing a “Follow TCP Stream” in Wireshark.
TCP stream of VNC authentication and keyboard commands
The authentication handshake is also using DES. The keystrokes are visible in ASCII Hex. Tools like Cain and Abel by oxid.it and PHoss by phenoelit.de, which have been around for quite some time – are able to sniff this handshake and crack it.
One of the tools for abusing the plaintext nature of VNC keystrokes is VNC keylogger by Jon Oberheide. It allows you to see keystrokes sent in real time given the ability to sniff traffic between the client and server. Keyboard emulating hardware such as the USB Rubber Ducky by Hak5 and similar products work by injecting keystrokes to perform action such as opening a command shell and executing a payload. I thought to translate this concept over to VNC to inject keystrokes and spawn a shell. Further research showed that this idea had been explored before. A metasploit module had been created last year for this very purpose.
Looking into the Linux documentation reveals that it works based off of your existing VNC server that comes with whichever version of Linux you are running. There is no software available to download. With that said, it’s time to turn our attention to MacOS (OS X).
For OS X Leopard (10.5) and Tiger (10.4) the instructions say to use Apple’s built in Screen Sharing utility, which is based upon VNC. Apple Remote Desktop (ARD) is tremendous security improvement over other VNC variants. Version 2, which was released in 2004 encrypted all keyboard and mouse movement. ARD version 3 encrypts all traffic including desktop graphics and file transfers.
The instructions for Leopard (10.6) and beyond recommend to download and run an app, called “HippoConnect.” It boasts additional features which are unavailable using the screen sharing method. After downloading and running the application, the user sets a password up to eight characters and the set-up is complete.
I became interested in where the application stored the password as well as how to application would continue to run through reboots. To little surprise, they use the preferred method by Apple which is by using LaunchDeamons and LaunchAgents. The information is stored in a .plist file, which is similar to XML.
HippoConnect .plist file contents
There are a couple alarming things here:
- The password is stored in plain text as a program argument
- The .plist file is word-readable
- The program is executed with root privileges
The security implications are that if this was a multi-user system, any unprivileged account can find the password to remotely control the screen of any user, as the HippoConnectAgent is running on boot. Any exploit of the HippoConnectAgent listener could result in gaining root privileges remotely.
Wireshark was used to evaluate how the HippoConnect protocol worked. As it turns out, it was quite similar to VNC.
TCP Stream of HippoConnect
As you can see from the screenshot, It authenticates using VNC authentication by passing a value to be encrypted by the secret DES key. The encrypted value is returned as the response. Seeing this, I wanted to replicate the the attacks available against the VNC protocol for HippoConnect.
The first hiccup I ran into was trying to get the challenge to encrypt properly. No matter how many times I tired encrypting the challenge with the key, I never got the proper response. I looked at the RFC for The Remote Framebuffer Protocol (RFB) which states:
The client encrypts the challenge with DES, using a password supplied by the user as the key. To form the key, the password is truncated to eight characters, or padded with null bytes on the right. The client then sends the resulting 16-byte response.
As it were, this doesn’t tell the whole picture. After some more research I stumbled across this post, which details the the missing information:
The actual software encrypts the challenge with all the bit fields in each byte of the password mirrored.
With this knowledge, the VNC authentication handshake could now be replicated.
I wrote a python script, which I have dubbed “AngryHippo” which can be used for exploiting these security issues.
Here is a quick video of the sniffer module in use. As you can see, the challenge and response values are printed to the screen, along with the status of the current keypress.
Sniffing Demo
Watch in HD https://vimeo.com/198123065
When you sniff the handshake, you can pass it to the cracking module to recover the plaintext key. When running against the rockyou.txt wordlist, which has about 14 million words, I was able to exhaust the list in 5 minutes on my MacBook Pro. If you require a complete brute force of the entire 8 character keyspace, I would suggest using one of the VNC crackers written in another programming language. Below is a simple demonstration of the cracking module using a small wordlist.
Cracking Demo
Watch in HD https://vimeo.com/198123111
Lastly, I created a module for keystroke injection. Currently the payload used is a simple bash reverse shell, in which you provide your listener’s IP and port for the reverse shell connection. An option is available to control the speed of the commands. This will likely be limited by the speed of the computer you are attacking. Using a MacBook Pro as the target, The speed was set to one millisecond per keystroke. I was able to inject keystrokes to spawn a reverse shell in a fraction of a second.
Injection Demo (Fast)
Watch in HD https://vimeo.com/198002869
In case that demonstration moved too quickly, here is a slowed down version injecting at a tenth of a second per keystroke:
Injection Demo (Slow)
Watch in HD https://vimeo.com/198003039
If you are curious to see if anyone is running the HippoConnect agent on your network, it is broadcasted over multicast DNS via Bonjour, Apple’s zero-configuration protocol. It listens on port 41660.
Bonjour Browser and Wireshark
AngryHippo can be downloaded at: https://github.com/n00py/AngryHippo
