Dropbox 15 – Dropbox Server (Boot Parameters)

By placing the configuration settings on a USB, we can dynamically change how the system boots. If necessary, we can send the client replacement files via email. This is critical if things don’t work after the device has already been deployed and we are still not able to connect. We can also use this functionality if we need to test multiple VLANs during a single engagement.

The settings that we will dynamically control include the following:

Network settings

Static/DHCP

Default gateway

DNS

Proxy settings

Authentication (Basic/NTLM)

authorized_keys

First let’s locate where the partition on the USB drive that we labeled ‘USB’ is mounted.

If we have to go through an outbound proxy then we will use the following config file for our SSH tunnels. Note that ncat ostensibly supports proxies, but would not create a connection to the HAProxy. I think it may have something to do with the CONNECT directive. No worries, though, as proxytunnel works just fine. Unfortunately, proxytunnel doesn’t support certificate checking by default. There is a fork by yarinb (https://github.com/yarinb/proxytunnel) if you want to pursue that. I’m not too concerned as it only affects connections where we’re using an outbound proxy and even if an attacker performs a MitM on our SSL/TLS connection we’re still performing strict host key checking on the SSH server. The certificate verification is honestly probably overkill.

In the above we are connecting to the client’s proxy server at 192.168.1.69 on port 3128 using Basic Auth as the user “pentester” with the password “squidward” and establishing a connection to our Dropbox Relay. For more information on proxytunnels or how to authenticate using NTLM instead, you can RTFM (http://proxytunnel.sourceforge.net/usage.php)

Finally, we’ll import the authorized_keys file. This will be the public key from your Dropbox Client. This is important if we lose access to our private key or if a consultant becomes unavailable and we need to grant access to another tester.

As we run commands from the config files as root, we have to encrypt everything!

If an attacker tries to replace a gpg encrypted config file with a direct command, e.g., cat /etc/shadow, then it will produce the following error message:

gpg: no valid OpenPGP data found.
gpg: decrypt_message failed: eof

If the attacker tries to gpg encrypt a command with a random passphrase/key, then it will produce the following error message:

gpg: decryption failed: bad key

So, let’s encrypt all of our example config files and place them in a subdirectory of the config directory. The gpg passphrase can be anything you want. We will use the same passphrase in our script files to decrypt the configs. Note, I’ve used one passphrase for the dhcp/static files, another passphrase for the direct/proxy files, and yet another passphrase for authorized_keys, but you can use the same for all.

This will delete the connection ‘dbox’ if it already exists, otherwise there will be multiple like named connections and that just gets ugly. It will also decrypt the network config file and setup the new ‘dbox’ connection.