Distributed Denial of Scheduling on Calendly

Time rules everything around us - and in business, Calendly has become the king of managing that time. Individuals, departments, and entire companies use Calendly as the beating heart of how time is apportioned for costly, synchronous meetings with real human beings.

It’s become such a ubiquitous tool that business culture has formulated protocol and etiquette around the use of the tool. Valued at $3 billion and with millions of monthly active users as of even a few years ago, the sheer economic value of time that is being scheduled through their service is a staggering amount to consider.

One of the things that bot-makers love about large companies that grow as big as Calendly is that they serve as a highly valuable target - if everyone’s using it, then when an exploit is found, everyone’s exposed to it. Earlier today, IPM’s co-founder dreamt up a small nightmare scenario:

Imagine a sales organization that uses Calendly to schedule their calls, or a support team that uses it to schedule service requests. At scale, teams that employ Calendly will by necessity have an extremely streamlined approach to its use - the process of scheduling calls becomes opaque, events just show up on people’s schedules as they are placed on them through automated systems, and so forth.

When large teams rely on trusting Calendly to take care of their scheduling, they are trusting that their time will also be protected from interference. What if a bot-maker wanted to slow down support tickets, sales, hiring, or other meeting-based teams to a crawl, and effectively interfere with their ability to schedule any events? Would it be possible to create a DDoS of such a system? Could we create what is effectively a distributed denial of scheduling?

To assess this possibility, we used the IPM Vulnerability Assessor to see how exposed Calendly is to bad behavior from bot-makers. In two minutes, we received a review of the state of their defenses on a temporary calendar we used to test their anti-bot measures. We found that nearly every bot was able to reach the page successfully - no apparent security measures were in place to prevent access.

Intrigued, we headed over to the Vulnerability Engine, our full-feature tool which allows the execution of bot behaviors of arbitrary complexity. In this case, we directed the bots to go to the demonstration calendar, select the first time available, and then schedule a meeting with our ersatz salesperson, Max Fischer. In total, our bots successfully scheduled 57 meetings to prove that we could meaningfully fill Max’s schedule.

A bot-created meeting for Max Fischer

A bot-created meeting for Max Fischer

From Max’s view, Calendly dutifully fulfilled our requests and started to fill up his work week, crowding out the potential to actually schedule meaningful meetings. Even if Max were to get rid of these meetings, the sheer magnitude of false positives could lead to deleting true positives out of necessity (i.e. real meetings from real clients) and potentially incurring very real losses as a result.

And from the Vulnerability Engine’s view, we saw our assortment of scheduled meetings along with the estimated time, code, bandwidth, and monetary costs incurred while engaging in the malicious behavior. All told, we estimate that a low-effort attack would cost $0.002 per scheduled meeting - with bot-maker specific improvements, we’d expect attacks in the field of almost any level of sophistication to cost less. Using our engineer estimator, we’d expect that an attack of this sophistication would take roughly a half work day to implement the groundwork for such an attack.

A look at the IPM Vulnerability Engine where we ran the demonstration attack

As with any attack, we’ve reached out to Calendly to advise on fixes - even low effort bot mitigation would likely help immensely in these situations - if there are any such measures, we have yet to see evidence of implementation.

Next
Next

Reverse Engineering how WAFs Like Cloudflare Identify Bots