Your MacPractice MD Server is Phoning a Friend

I was troubleshooting a MacPractice MD Server the other day for a client. I noticed some strange behavior and decided to look at some network statistics. I found an established connection to an address that resolved to an Updox server. Updox is integrated into MacPractice MD as a paid extra of sorts. You can read more about Updox and their relationship with MacPractice on the Updox website. The fact that the software is phoning a vendor’s business partner instead of the vendor directly is why I have titled this entry as Your MacPractice MD Server Phoning a Friend instead of Your MacPractice MD Server Phoning Home.

The real issue with these connections is that the client I was working for did not pay for that extra feature. They had no contract with Updox and had no business purpose to communicate with them. They had previously expressed interest in using Updox with MacPractice MD for electronic FAX but did not pursue it after checking out the cost. No trial was ever started. Why was this MacPractice MD Server connecting to Updox servers? I met with my contact and explained what I found. I was curious and wanted to find out more. Ultimately this was not the cause or a symptom of the problem which I had been contacted to solve. I didn’t seek written permission to capture and analyze network traffic (I didn’t want to open a can of worms over my own curiosity.) but I did ask for permission to access the Cisco Meraki hardware and logs. The client and network administrator were more than willing to let me look further into this if I wanted to. Hell yes I did.

The connections from the MacPractice MD Server to Updox happened regularly and were over port 443 to That IP address resolved to Although I did not capture and dissect any network traffic I was able to verify that the IP address was listening for https on port 443 by establishing a connection with my own Mac. It was expected but worth verifying. In a 24 hour period the Meraki Security Appliance logged 1440 flows between the MacPractice MD Server and this IP address. (Note: A flow is defined by the firewall as one connection socket. The number 1440 reeks of automation. It also seems excessive. Over the 24 hour period a total of 5.5MB was transferred between these two machines and about 2.5MB of that was egress traffic. Not a whole lot of action. With 100% certainty I can say that the MacPractice MD Server makes these connections. Any assumptions beyond that are just those – Assumptions.

I would love to set up a test MacPractice MD Server with ZAP or Burp Proxy to have a better idea of what’s going on inside of those connections. I’m unable to test any hypothesis I may have about this until I’m essentially gifted a MacPractice MD Server license. Ideally I would be able to research this issue to either confirm my hunch that this traffic is benign or to be gifted with a juicy surprise. I’ve ragged on MacPractice before for a handful of reasons. Nevertheless it would be fun to find out what exactly is going on and potentially fix an issue. Even if it’s just for tidiness.

Your MacPractice MD Server is Phoning a Friend

OS X’s tcpdump

I was messing around with non-recursive DNS queries today and noticed that the version of tcpdump that comes with OS X is special. (Why wouldn’t it be?) It’s compiled with a -P flag which allows it to save pcap-ng files as opposed to pcap. Pretty nifty. In the man page the following is said about the hook:

-P     Use the pcap-ng file format when saving files. Apple modification.

Pretty nifty!

OS X’s tcpdump

Apple FaceTime, Telemedicine, and HIPAA

Doctors want to provide the best care for their patients. Being able to check in with them more frequently and in a meaningful way allows them to provide that care. Many providers in small practices are interested in telemedicine.

Can you use FaceTime for telemedicine?

I wouldn’t and I want to show how I formed that choice. It’s largely due to three reasons:

1. There is no central management or accountability for FaceTime

The only management or accountability comes from the owner of the FaceTime account. If you’re thinking of how to manage an Apple ID please keep in mind that Apple IDs are not required for FaceTime. You can use it with only a phone number and an iOS device.

No management means no policy enforcement. You can’t enforce password requirements for a FaceTime account or Apple ID. You can’t audit FaceTime account behavior. We are unable to detect a compromised account or deviant behavior.

2. Apple won’t sign a Business Associate Agreement

Apple will not sign a Business Associate Agreement (BAA) for their FaceTime service. There seems to be a misconception that Apple falls under the Conduit Exception Rule. The main article promoting this idea fails to test the hypothesis that your FaceTime session is routed through Apple. In reality, FaceTime audio and video data is never sent to Apple. The Conduit Exception Rule does not apply to Apple in this context. The Conduit Exception rule would instead apply to the Internet Service Provider (ISP) that your FaceTime session is traveling over, such as Time Warner, Level 3, etc. Again – The FaceTime audio and/or video data is never sent to Apple. You can test this by capturing network data and analyzing it in Wireshark or a similar program. You will find that while the notifications and coordination for FaceTime originate from Apple ( the FaceTime session data is encrypted and between the two endpoints only.

Does this help the case of making Apple FaceTime HIPAA compliant? Yes and no. The whole “Apple falls under the conduit exemption rule” argument is moot but we still have the previous hurdle – which is a big one – to overcome. If it’s not possible to centrally manage FaceTime accounts, audit them, or apply policy to them, then count me out. This doesn’t pass the sniff test.

It also doesn’t get us past the fact that Apple will not sign a BAA for FaceTime.

3. FaceTime leads to Apple IDs, Apple IDs lead to iCloud, iCloud leads to the dark side

Have you ever asked for trouble? Using iCloud in a HIPAA environment is just that. iCloud has many storage features such as iCloud Drive and Photos – none of which are HIPAA compliant. If you have an iCloud account it’s insanely easy to accidentally enable these features. What I would really like is a way to manage or restrict Apple IDs and iCloud features for use in the enterprise. I do not anticipate Apple having these. Ever.

As an administrator I wouldn’t want to inadvertently encourage or endorse the use of iCloud accounts in a HIPAA environment. I love using my personal iCloud account for contacts, calendars, and other features. In the medical environment iCloud accounts should be avoided.

Compliance is not security

Let’s get something straight – Compliance and security are two completely different things. This post is me listing out why I would not recommend FaceTime. The problems that I have with FaceTime are not technical in nature. FaceTime appears to be incredibly secure and not HIPAA compliant.

I use and recommend FaceTime for personal calls and video chats. I would not use it for telemedicine.

Am I willing to change my mind?

Absolutely. I would want support from legal in the form of review and approval of FaceTime in a HIPAA setting and from Apple by accepting and signing a BAA.

Final Thoughts

I believe that you take on an unfair amount of risk by using FaceTime for telemedicine. My hangups largely have to do with accountability and management and not with the technology or security measures used. If Apple would sign a BAA, or if the issue is discussed with legal council familiar with HIPAA and given the thumbs-up, I would recommend it’s use for telemedicine.

It’s worth noting that the U.S. Department of Veterans Affairs (VA) approved the use of FaceTime with constraints. The constraint in question:

Users should check with their supervisor, Information Security Office (ISO) or local OIT representative for permission to download and use this software.


I would not grant that permission and I would not look to the VA for HIPAA compliance guidance. (See Privacy Violations Rising At Veterans Affairs Medical Facilities and Few Consequences For Health Privacy Law’s Repeat Offenders.)

Apple FaceTime, Telemedicine, and HIPAA

OS X Sockets and Their Processes

How do we list sockets with the process names and PIDs that occupy them in OS X?

Imagine that our goal is to get a list of listening TCP sockets on OS X and the process names/PIDs that are using them. How would we go about displaying this data? We can start by asking ourselves how we would do it in Linux.

Using ss

In Debian GNU/Linux we can use the ss command with the -n (do not resolve service names) -l (display listening sockets) -p (display process using socket) and -t (display only TCP sockets) flags.

root@debian:~# ss -nlpt

This gives us the output that we are looking for. Once we move to OS  X we discover that the ss command is not available. We always want to live off the land and not install anything special to gather our data. Using ss is not an option and we move on to netstat.

Using netstat

Although netstat and ss are different programs the flags in this next example have the same meaning. (As we’ll see this is simply not true for the netstat build included in OS X.) Use the following command/flag combination in Linux.

root@debian:~# netstat -nlpt

Like ss, netstat on Linux gives us the output we are looking for. Even better is that OS X comes with netstat. Let’s try that same command/flag combination in OS X.

osx:~ root# netstat -nlpt
netstat: t: unknown or uninstrumented protocol

The OS X build of netstat has flags that are different than what we expect on Linux. Some flags have different functions while some functions simply do not exist. Notably here the -p flag does not display the process name and PID in OS X. Instead it is used to specify a protocol to filter. The error above is the result of us specifying the protocol t, which does not exist. (Rearranging our flags will give us a different error but the cause will continue to be our -p flag not being provided a protocol to filter.) The real bad news comes when we read the OS X netstat man page and find out that there is no flag to display the process information that we are looking for.

This is an obstacle for us but not one that we can’t overcome. We can move on to lsof.

Using lsof

We can use lsof to do a lot of things, one of which is to show socket information. In fact we can use the right flags to display the exact information we are looking for.

Here’s the command and flags that I tend to use in OS X. Run it in both Linux and OS X to verify that the application behaves identically on each system.

root@debian:~# lsof -nPl -iTCP -sTCP:LISTEN
osx:~ root# lsof -nPl -iTCP -sTCP:LISTEN

The command works and we get the identical output formats in both Linux and OS X.

We can display and collect the information we are looking for.

Too Long; Didn’t Read

Use the following command/flag combination in OS X to list listening TCP sockets with the process name and PID associated with them.

osx:~ root# lsof -nPl -iTCP -sTCP:LISTEN

You can check out the lsof man page to change the display options and filters as necessary. Many options are available and piping any output into grep may provide additional granularity.

Do you know of a better way?

Let me know! I’d love to know of any better or different ways to gather this kind of data in OS X.

OS X Sockets and Their Processes