Subject: [calsify] Calendar spam - it is speeding up - security issue / warning

From: Doug Royer <[email-masked]>
Date: Thu, 13 Jun 2019 19:13:10 -0600

Years ago, I predicted without more controls (no clue what), that 
calendaring can be used to attempt to schedule appointments and spam.

No proposal from me. Perhaps after reading the article below, new 
security controls may be needed soon. It might make a new great topic / 
draft. Clearly - do not click on appointments in email to find out what 
they are about.

This article is pointing out the latest calendaring security abuse. (it 
is a bit of pay-to-view, you can still read it).

Summary, spammers are sending out calendar appointments with URLs that 
look like appointments (and are fake links or malicious links), or have 
valid iCalendar objects that have or link to malicious calendar 
attachments. The MUA/CUA or perhaps user is being careless about what is 
loaded.

The original post that led me to this article pointed out that 
Thunderbird with the calendar add-on, may be vulnerable to this.

Not entirely new or new news. But it seems to be picking up.

https://www.forbes.com/sites/daveywinder/2019/06/11/new-security-warning-issued-for-googles-1-5-billion-gmail-and-calendar-users/#700c55f7565e

No proposal from me. Just for those on this list, if you happen to have 
an idea for helping slow or stop this kind of thing, it may be time to 
rethink iTIP and calendar security.

-- 

Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: David Thewlis <[email-masked]>
Date: Thu, 13 Jun 2019 19:10:09 -0700

FYI earlier this year, CalConnect published a best current practices for calendar operators on calendar spam.  This was developed in conjunction with M3AAWG; we understand that they will be publishing it as well.  See https://standards.calconnect.org/csd/cc-18003.html <https://standards.calconnect.org/csd/cc-18003.html>.

Dave Thewlis

> On Jun 13, 2019, at 18:13, Doug Royer <[email-masked]> wrote:
> 
> Years ago, I predicted without more controls (no clue what), that calendaring can be used to attempt to schedule appointments and spam.
> 
> No proposal from me. Perhaps after reading the article below, new security controls may be needed soon. It might make a new great topic / draft. Clearly - do not click on appointments in email to find out what they are about.
> 
> This article is pointing out the latest calendaring security abuse. (it is a bit of pay-to-view, you can still read it).
> 
> Summary, spammers are sending out calendar appointments with URLs that look like appointments (and are fake links or malicious links), or have valid iCalendar objects that have or link to malicious calendar attachments. The MUA/CUA or perhaps user is being careless about what is loaded.
> 
> The original post that led me to this article pointed out that Thunderbird with the calendar add-on, may be vulnerable to this.
> 
> No proposal from me. Just for those on this list, if you happen to have an idea for helping slow or stop this kind of thing, it may be time to rethink iTIP and calendar security.
> 
> -- 
> 
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and Scheduling Consortium
+1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | [email-masked]

---

From: Doug Royer <[email-masked]>
Date: Thu, 13 Jun 2019 20:57:52 -0600

On 6/13/19 8:10 PM, David Thewlis wrote:
> FYI earlier this year, CalConnect published a best current practices for 
> calendar operators on calendar spam.  This was developed in conjunction 
> with M3AAWG; we understand that they will be publishing it as well.  See 
> https://standards.calconnect.org/csd/cc-18003.html.
> 
> Dave Thewlis

Great! Just read it for the first time. I did not know it existed.

Should drafts start using 'https' and not 'http' in the examples? It is 
not just about security over the wire. It can be about verifying the 
destination host is from a verified and expected site. Should https be 
required for all links in the future?

I could add a URL into an iCalendar property/ parameter that links to a 
.DOC file that has malicious code. Several proposals lately have added 
or used URL links to related documents.  Some CUAs could execute the 
related viewing application themselves after the user says 'yes' to load 
"YourIntroPacket.doc" - without virus checking.  This is a security issue.

A warning about the user saying "yes" to download and not automatic 
loading is the first half. Virus checking and malicious site checking is 
the second (and not mentioned) half.

Last time I wrote a CUA, I just used the OS call to load and view the 
reflated application using the OS 'start the correct application' calls 
- without checking.

--

---

From: "Thomas Schäfer" <[email-masked]>
Date: Tue, 18 Jun 2019 18:23:04 +0200

Hi Doug,

Thanks for pointing to the mentioned article.

Members of CalConnect started thinking about this as soon as the big wave of calendar spam hit Apple users in November 2016 (https://www.bbc.com/news/technology-38144377). We soon started working on it by issuing article describing what happened (https://www.calconnect.org/news/2017/01/30/calendar-spam) and also started reaching out for E-Mail people at Messaging Malware Mobile Anti-Abuse Working Group (M3AAWG, https://www.m3aawg.org/) to work together on the topic.

In 2018 we finally managed to agree on working together on the topic (https://www.calconnect.org/news/2018/04/05/taking-calendar-spam-scheduling-developers-organization-calconnect-collaborates) and as Dave mentioned, the result was our published Calendar operator practices — Guidelines to protect against calendar abuse (https://standards.calconnect.org/csd/cc-18003.html) which also includes suggestions for mail and calendar service providers how to address the topic. Which now waits to be co-published by M3AAWG as well.

You are right, that the document may also address the area of calendar client developers a little bit more, but unfortunately we were not able to attract people developing clients to join.

Regarding some of your points:

>Virus checking and malicious site checking is the second (and not mentioned) half.

It is mentioned in https://standards.calconnect.org/csd/cc-18003.html#toc15 and https://standards.calconnect.org/csd/cc-18003.html#toc18, but as said, it does not contain a deep section about expected calendar client behaviour, as it aims for not inserting malicious events in your calendar at all and therefor preventing them to appear in your calendar client.

Thomas Schäfer
chair of TC CALSPAM @ CalConnect

> Gesendet: Freitag, 14. Juni 2019 um 04:57 Uhr
> Von: "Doug Royer" <[email-masked]>
> An: [email-masked]
> Betreff: Re: [calsify] Calendar spam - it is speeding up - security issue / warning
>

---

From: Doug Royer <[email-masked]>
Date: Tue, 18 Jun 2019 11:39:39 -0600

On 6/18/19 10:23 AM, "Thomas Schäfer" wrote:
> ...

That is great, however these are IETF documents. And I am NOT talking 
about SMTP or EMAIL (the references you pointed to). I am talking about 
URLs to external documents that could have been transferred with a 
MAILTO URL. However, the examples in the drafts are using an HTTP url 
(not covered under SMTP or EMAIL and not transferred with SMTP).

Email virus checking might find that related document URL contains 
malicious content if it were a multipart/mime with a CID, or as a 
related and inline included content. However it is often the case that 
the calendar embedded URL point to external documents.

Not all calendar objects are transferred with IMIP. Enterprise internal 
hacking, WebCal, or just a link someone puts on some public sporting 
event would not be transferred with iMIP. All of which could have 
related document URL links that point to malicious items.

And related: can an RFC refer to a calconnect document as a NORMATIVE 
reference?

--