a brief on the most popular consumer cloud storage protocols along with suggestions to mitigate the threat of data exfiltration via these services on corporate networks.

1. Data Security Governance and
Consumer Cloud Storage
Understanding the technologies and detecting the threats

2. CCS: Definition
• Consumer Cloud Storage services (CCS) are cloud-based
file systems used to store, retrieve, back up and share
files between multiple users and devices
• Extremely popular, wide market penetration
• Variety of feature differentiators between providers
• Security and operational models vary by provider

3. Methodology
• We’ll use a dtrace script to print out all outbound tcp
connections and their associated processes and then we’ll
manipulate the applications to see if we can make a correlation
between function and TCP stream
• Install the CCS package while running the ‘opensnoop’ dtrace debugger
and capture the opensnoop output.
• Start the CCS client daemon while running a tShark capture, along with
opensnoop and the soconnect_mac.d dtrace script, logging the output.
• Examine the resulting pcap file and extract the individual TCP sessions
logged by the soconnect_mac.d script. Make note of the ports,
protocols, and networks utilized in the sessions.
• Using the same monitoring techniques, perform file upload,
modification, and deletion operations to the directory monitored by the
service and note any differences (if any).
• Examine the files accessed by the process(es) to determine if any
useful data or correlations can be gleaned.

4. Dropbox Client Initialization
• Upon client startup:
• DNS: Standard query A clientXX.dropbox.com
• clientXX may be any number between 0-99 (dynamically
generated by a call to /dev/urandom)
• all records are CNAMES for client.dropbox.com
• This is likely a way to prohibit clients from hardcoding a single IP
address in a host file and thereby always directing traffic to a
single login server
• DNS returns list of available client login servers
• All servers within the 199.47.216.0/22 subnet, specifically
199.47.216.159-174
• Server IPs are load balanced to provide load sharing over pool.

5. Dropbox Client Initialization (cont’d)
• Client selects last IP address returned from the query
• Client establishes TCP connection to this address on port
443 and negotiates TLS encryption
• All traffic for this TCP session is now encrypted
• However, we also see Dropbox connections to
• 108.160.161.159 (talk.google.com)
• 199.47.216.172 (block servers)

6. Dropbox Flows
Login,
registrations,
Filesystem
updates
https
Client Metadata Servers
v-client-XY.sjc.dropbox.com
199.47.216.172
199.47.216.173
199.47.216.174
199.47.217.172
199.47.217.173
199.47.217.174
199.47.218.159
199.47.218.160
199.47.218.159
199.47.218.160
DNS Query
Local DNS Query for
clientXX.dropbox.com
XX is 0-99
DNS Response
DNS responds with A records for Auth
and Notification Servers (below)

7. Dropbox Flows (cont’d)
Upload file
index &
check for
changes
https
Upload/
download
new changes
https
Block Servers
dl-clientX.dropbox.com
(X=1-780)
All hostnames resolve to Amazon S2
Cloud Storage Servers on the
following Amazon networks:
204.236.128.0/17
174.129.0.0/16
184.72.0.0/15
23.20.0.0/14
50.16.0.0/14
107.20.0.0/14
23.20.0.0/14
75.101.128.0/17
Notification Servers
notifyxx.dropbox.com
x = 1-40
108.160.160.0/20
Receive update
notifications
http

8. Dropbox: Interesting Traffic
(The smoking guns)
• XMPP connections to talk.google.com
• from="gmail.com"
id="BC175DBCBFCBDADD"
version="1.0"
xmlns:stream=http://etherx.jabber.org/streams
xmlns="jabber:client”
• IP connections to a known block server

9. Detecting Dropbox on the Network
• IDS signature
• Cleartext registration with Google Talk servers
• alert tcp $MY_NETWORK any -> $EXTERNAL_NET $HTTP_PORTS
(msg:"DROPBOX.COM services in use"; flow:established,to_server;
content:"/subscribe?host_int="; http_uri; content:"&ns_map="; http_uri; >
content:"&ts="; http_uri; content:".dropbox.com|0d 0a|"; > classtype:policy-
violation; sid:1; rev:1;)
• Augment IDS with log file analysis of DNS server traffic
• Some sophisticated stuff can be done here to ensure that multiple data points are being
analyzed prior to alerting

10. Google Drive
• The Google Drive service relies upon DNS load balancing
to provide geographic and resource diversity. The Google
drive client begins by querying for clientsX.google.com
(where X is a randomly selected integer between 1 and 5)
• The client’s local DNS server returns a CNAME of
clients.l.google.com and load balanced dynamic list of 11
IP addresses in one of two IP ranges:
• 74.125.236.96/28
• 173.194.36.0/28

11. Google Drive: Traffic Flows
Login,
registrations,
Filesystem
updates
https
Registration and Notification Servers
clients.l.google.com
74.125.236.96/28
173.194.36.0/28
Upload file
index &
check for
changes
https
DNS Query
Local DNS Query for
clientsX.google.com
X = 1 - 5
DNS Response
DNS server responds with CNAME
clients.l.google.com and load balanced
dynamic A records in ranges:
74.125.236.96/28
173.194.36.0/28
DNS Query
Local DNS Query for
upload.drive.google.com

12. Google Drive: Traffic Flows (cont’d)
Upload/
download
new changes
https
Block Servers
74.125.131.116 74.125.131.117
XMPP Servers
talk.google.com
74.125.131.125
74.125.133.125
Receive update
notifications
http
DNS Response
DNS server responds with CNAME
large-uploads.l.google.com and A
records:
74.125.131.116
74.125.131.117
DNS Query
Local DNS Query for
talk.google.com
DNS Response
DNS server responds with CNAME
talk.l.google.com and A records:
74.125.131.125
74.125.133.125

13. Detecting Google Drive on the Network
• No choice but to use a signature based upon DNS queries
• alert udp any -> any 53 (msg:"DNS Query for Google Drive
Upload Server"; content:"|01 00 00 01 00 00 00 00 00 00|";
depth:10; offset:2;
content:"upload|05|drive|06|google|03|com|00"; distance:0;
nocase; classtype:policy-violation; sid:2; ver:1)
• Augment with host based file analysis to differentiate other
Google services from Google Drive

14. Microsoft SkyDrive
• Similar to Google Drive, SkyDrive relies upon Microsoft’s
server and network resources shared by other Microsoft
services. Client initialization begins with an DNS query to
the local client’s DNS server for login.live.com. The query
returns a CNAME of login.live.com.nsatc.net and eight
IPv4 address records within the ranges of
• 65.54.186.0/25 and
• 65.54.165.128/25.

15. Microsoft SkyDrive: Traffic Flows
• A mind boggling number of TCP connections
• 13 HTTPs connections to various Microsoft servers within 13
seconds of usage
• All connections are https only
• DNS queries are for login.live.com
• No way to differentiate between other services that leverage
live.com

16. Detecting SkyDrive on the Network
• Don’t use IDS/IPS (for now…)_
• Watch future iterations of the client releases to see if any non
encrypted traffic is introduced into the flows
• It may be possible to learn more about the architecture of the
service as it matures (Dropbox made this easy. Google made
it harder. Microsoft made it positively nightmarish).
• Instead, focus on file-based analysis to detect SkyDrive
usage:
• ~USER/Application
Data/Microsoft/SkyDrive/SkyDrive.Resources (Mac OSX)
• ~USERAppDataLocalMicrosoftSkyDriveSkyDrive.Resourc
es

17. Wrap Up
• The increase in CCS use is not going to decline
• The most popular services are treated as embedded
features
• These embedded features utilize the same backend as
less threatening services
• IPS/IDS cannot solve the problem on it’s own

18. Wrap Up (cont’d)
• We have to augment InfoSec training to include reasoned
arguments against using these services in the work place
• We need to augment our technical controls to include file
based detection instead of just network detection
• Corporations should definitely consider Enterprise File
Sharing Applications (Accellion, etc) to bridge the gap
between user demands and the security needs of the
environment.