hello and welcome to the three o'clock track three talk you have one new opponent hacking
proprietary i calendar properties by eugene lim before we begin i have two announcements
number one please wear your masks while you're while you're sitting in the room that they're
still required and number two please don't sit around or stand around the edge of the room
please come in and find a seat come on a little closer and check out the stock welcome eugene
hi everyone um thank you so much for coming i know it's day two of defcon so you guys have
survived uh you guys just have to survive my talk and one more day and you guys will be home free so
thank you very much for coming and i'm really excited to speak today i'll be talking about
you have one new appointment hacking proprietary i calendar properties and before i begin i just
want to give a quick introduction to myself i'm eugene and i go by space raccoon online
and that's my twitter handle because someone has a twitter handle for space raccoon so if you're
that guy come up to me we can work something out after this um you know i can't pay much but we'll
figure something out i work at the cyber security group at the government technology agency of
singapore so i'm from singapore and what i do is mostly devsecops i work on protecting citizen
data and government systems and applications before they get out into the public yeah
so how many of you guys have gotten a appointment reminder
in the last week or so you know maybe a ping a mobile notification yeah most of you guys do
because especially in the covet post covet or well you know era you know we have a lot of calendars
invitations kind of floating around reminding you to go for something or another and you might
be wondering what's going on behind the scenes right when you get an invitation and you have
that little convenient button in outlook that says accept the invitation or decline the invitation
what's happening right or in your apple calendar or your ios device you might also have that
convenient button so what really happens when you get an invitation and it pops up
and you might also wonder what happens if instead of just accepting an invitation or you know
checking out an application invitation they've gotten what happens if you started doing something
strange right your mobile phone starts having a few pop-ups you might start a call something might
be going on in the background and you don't start the meeting right instead a shell or something
what really goes on behind the scenes when you have an invitation like that is that you have
an email with an ics attachment which is the iCalendar attachment and before we carry on i
just want to clarify i think maybe a misconception some might have is that iCalendar is not explicitly
a apple format you know because you might think iphone ipad but the iCalendar format is actually
the name for a standardized format defined by rsc that's interoperable between various
email and calendar clients from microsoft outlook to google calendar to apple calendar
it's something i'm going to dive a bit more into because for those of you in red teams you might
be pretty familiar with using calendar invitations as a phishing deal and that's something that a lot
of people have done but was it more interested in was looking into exploit scenarios with the
iCalendar format ways that it could be used and abused ways that passes can be broken
in order to get an exploit out and this was fairly fruitful research even though i threw
the net pretty wide so this kind of covered a number of vulnerabilities from vmware boxer
to synology calendar apple calendar microsoft outlook google calendar and next cloud calendar
so if you look at the list of targets it's actually a fairly broad range because it went from mobile
to web to desktop to iot devices and this really shows you even from a very brief survey that i did
across you know every single client i could get my hands on i didn't really go too deep into one
or another that you can find a lot of interesting things and this brought up a few interesting ideas
so we really have to begin i think about 24 years now back in 1998 when the rfc2445 which
is the internet calendar object specification was first published by two guys dawson from
from lotus and also stanerson from microsoft and what these guys came out with was basically
a format for the iCalendar specification which would define an event or calendar that could be
between various office applications and back in 1998 that was the context was that it was a huge
office wars right because all these companies were coming out with their own office suites
you know they were creating their own specifications their own way of doing things
and they're not all compatible with each other but this is a terrible thing for the end user because
it doesn't make sense if you as a user have an event and you're inviting someone and it doesn't
matter what kind of client they're using or what kind of application they're using you want them to
accept your invite and attend it but if you're all using different formats that's not going to
work out right so that's what these companies did they came together built a format and they decided
to use that as a standard operating format between each of them and so that's really
the the plan they have for today i'm going to give you kind of a background to the iCalendar
format some interesting things that might have came up in my research and what what people might
have exploited before diving into standard implementations of iCalendar that are not so
standard so even though you have a standard i think you'll be more than familiar that companies
don't do things that way they have used it in very interesting and strange ways that have left
to vulnerabilities and then i'll move on to proprietary extensions to the iCalendar standard
i'll talk a bit more about that later but basically the iCalendar standard supports a non-standard
way a standard way of doing non-standard things so companies can add their own extensions their
way of passing and that's going to be supported by the format and then finally i'll talk about some
of the things that iCalendar supports and that's going to be supported by the format and then
iCalendar doesn't exist in a vacuum when you respond to an invitation and email is being sent
so it's working with the smtp format there's also the caldev format protocol which helps to
update and create calendar files on the web service and and that's all kind of things that
add additional complexity to using iCalendar and has led to vulnerabilities and i'll give some
takeaways quick takeaways mostly for builders but also for breakers if you're interested i'll be
also putting up a small database of these stuff that i found that you can also take it a bit
further because as i mentioned i've done a really broad survey found really kind of surface level
stuff but from what i've seen i think if you want to take it further there's definitely a rich
source of bugs all right so let's start with the background for the iCalendar standard so i showed
you the 2445 rfc that was way back in 1998 and it was kind of superseded by what is 5545 which
is the iCalendar format done by someone from oracle and more recently we have seen also a
couple more updates more the most recent one also from apple engineer from apple but you also have
a bunch of other rfc's that kind of update or add kind of interoperability things that basically
extend the format to more platforms but when you think about the iCalendar format you really want
to go with irc5545 because that's a core specification that tells you exactly what goes on
into this format all right so that's enough of talking of the iCalendar standard so let's move on to the iCalendar standard
so what actually goes on in a calendar right you get a calendar invite what's going on you get an
email with an ics attachment and what does that ics attachment look like so that's what it kind
of looks like it's a pretty interesting format a very simple format something that you might come
up with back in 1998 when you had a lot of space and network restrictions it's a text file comma
delimited and new line delimited and it's a bit similar to say xml because there are some opening
you have the opening of a v calendar and you have opening of a v event and those are things that
are similar to xml but it's also different from xml because it also has key value pairs right you
have stuff like the date type date time start the end the location the url and these are all
standard properties to help describe the event you're attending and in the background what the
clients are doing are essentially passing this transparently to the user so as a user most of
the time you're not going to see an ics file you might have seen that in the past but you're not going to see an ics file you might have seen that
if you have been sending an invite to a separate email client but you're sending it within the
outlook ecosystem for example what you're going to see is a very streamlined and transparent kind of
user interface right and what these clients are doing is that they're doing some propriety work
in the background they are passing it differently from other clients they are also adding their own
extensions and this creates more features because these companies they want to differentiate their
products so you might have gotten a very convenient join online button if you had a team meeting or a
meeting and what's going on back there is that outlook is actually passing for example the url
property or maybe the custom proprietary property that defines the team's meeting url and that's
going to immediately appear in the gui so that's already pretty interesting because just by modifying
some of these unstructured data you can create changes in the gui and also the behavior of these
applications you might have a flight scheduled tomorrow i hope it stays on time
um but basically when you have a flight and it comes in as an email for example apple mail is
able to pass that intelligently extract some of the features and suggest event for you right and a lot
of this data is actually going to be in apple's proprietary data format so it can show you things
like your travel time it can do a bit of a tracking of the flight for you and the calendar
and that's all very convenient for the end user but with that convenience it comes
some complexity and for bug hunters i think that's
where the bugs happen so back in i think 1998 there were some dangers by default
stuff in the specification and one of these is the v alarm v alarm property right so you can specify
an alarm or trigger that happens maybe 15 minutes or one hour before your event happens and you can
pop it in different ways the most obvious way is of course the notification way so it's just going
to pop up a box or something but back then they actually allowed for several other ways to create
a notification one of them is that you could specify an email that could also have an
attachment from your local for a local system so when it's time for the event it's going to send
an email to who knows what with whatever attachment you have specified in your local
system or you could even play a sound a special sound so you could load that from an ftp server or
http server in a remote server and we can see why that is might be an issue today because you know
you could play something nasty or dangerous and you don't want that to be loading remote content
and that was something that would have been possible given the way icalendar works because
a lot of these systems they just take in the icalendar file and they automatically add that
to your calendar without you even having to accept it but that was back in 1998 and i think
a lot of companies and also the new updated rfcs they have kind of noted these dangers by default
stuff they've kind of deprecated it but they're still insecure implementations of standard rfc
properties and i'll go through them through some of them they're really interesting
so the first one is the description property and it's as simple as it gets it's exactly what it
says on the tin it just describes the event that you're going for and it's meant to be a raw text
file right it just adds in a little more data about what's going on with your event
but even though it describes it as a raw text file i think vendors implement this
very differently so apple and microsoft you know they stuck to the specification
they interpret that as plain text but google and vmware they actually interpret this as
gmail so if you can you can actually include html tags and it will be passed as such google
itself does have their own sanitization procedures you might be familiar with those vmware did not
for one of the applications as i mentioned earlier the reason why this is a problem is just
because of the way ics works for a lot of clients they automatically add the ics attachment to your
calendar so even if you haven't accepted it or declined it it's going to appear in your calendar
it's going to be added as a non-blocking event until you respond to it but it's going to be there
and because of that you can trigger a payload remotely without any user interaction
depending on of course the the exploit scenario that you have as well and that's something that's
pretty concerning and also what makes it tricky is that you know you have so many clients across
different platforms different frameworks that makes it really difficult to secure
your implementation so for vmware that was an interesting case because only the ios application
was vulnerable whereas android has a different way of handling web views and that was able to
kind of sanitize it and kind of block the exploitation whereas if you look at stuff
like what microsoft is putting out they do have microsoft teams windows calendar outlook outlook
on the web they have mobile desktop all kinds of things and this makes it a lot messier for you
to secure things at the end point and this is something i observed as well where it kind
of pays to kind of test across different platforms and different uh versions in order to get what you're looking for.
It pays to kind of test across different platforms and different uh versions in order to get what you're looking for.
what you want to see.
What's interesting as well is not just raw text parsing.
Apple does something really weird with this format
because while they stick to raw text,
they actually add their own special template into this.
So it has a magic template, magic bytes,
and if you're creating an application event
with a FaceTime call,
what it actually does behind the scenes
is that it puts in this FaceTime format template
and it transparently interprets that in your clients.
So if you're gonna look at that on your mobile phone
or in Mac OS, it's just gonna show you
a simple join button.
At this point, you're kind of like,
okay, yeah, custom URIs are also a thing.
So Apple back then didn't sanitize it
and this is also a concern because I think
in the start of 2022, I think Ryan Pickering
had a really good UXSS or custom URI
to RCE exploit on Mac OS.
So this would have been a great delivery mechanism
for that kind of vulnerability.
And really, I think when it comes to a lot of the properties
I've seen that involve a URL,
some of them do not check for the custom URI or protocol
and that's where you can also put in an exploit.
Another interesting property for me
was the attendee or organizer property.
And what's interesting about this
is that it's also tied to how you respond to it, right?
Because when you respond to an email
saying you're attending or not attending,
it refers to the, you know, you're attending or not attending.
It refers to the organizer field
and it's gonna send invitation response to that organizer.
And then the server at the end of it
is gonna accept the invitation
and then it's gonna send an update
to all of the invited participants.
So according to the RFC, this value is a URI
and has to be a mail-to URI defined by another RFC, right?
And sure, you're like, okay, that's fine.
That looks good to me.
But I think for those of you who look at RFCs,
my condolences, for those of you who read RFCs,
you know, that's a valid RFC-approved email, actually,
because you put it between double quotes,
it allows special characters,
and that's where you can also inject some of your payloads
that are gonna be used by the application.
So this was something I saw with the Synology calendar itself.
So for example, when you add an event,
and I'm just kind of importing it here,
but you can have it synced from a calendar
or from someone inviting you, that's gonna cause, you know,
a payload, right, and that's gonna pop.
Yeah, and you can create a warmable event from this,
basically, because it's a calendar,
and then everyone's invited to the party,
and it's not a good party, it's the bad party,
the kind that you don't wanna go to at, you know,
I hope you've gone to better parties, that's DEF CON.
Yeah, and also, some of the behavior that Apple does
is also very custom, very proprietary.
It's a nonstandard way of implementing the specification
that's really interesting.
So for a calendar, they also have an attached property.
And an attached property basically defines, you know, most of the time it has to be a
local to your email itself, but you can also sometimes specify a URL.
Most clients do not support that.
But this URL specifies attachment to your event.
So stuff like maybe a meeting agenda or a cat picture or something.
And what Apple does is that it checks if this URL ends with .icloud.com, and if it does,
it's going to automatically download that to your computer.
And this might be useful for red teams.
I mean, I think it follows icloud.com, but it also follows redirects, so you can load
any of your remote data into someone's computer remotely.
So it's a zero-click download, I guess.
And that might be useful for some red teams.
It also does, if it's on .icloud.com, you can basically sign up for an iCloud folder,
and you can also upload that, and that's going to work with everyone.
So it might be convenient for the end user because it helps them quickly attach stuff
to iCloud and send it to each other.
But it's also useful.
It's useful if you want to deliver a payload.
So that's it for kind of the standard properties that we've looked at.
And one of the other things that I started to look at was the proprietary extensions
to iCalendar.
And that really makes the meat of kind of what I'm going to talk about today.
I love it when companies do things differently because then, you know, bugs happen.
And the RFC has a specification that allows for a standard mechanism for doing non-standard
things.
And what that means is that if you want to add your own functionality, you want to add
your own custom property that's not in the RFC, something a little extra, you can just
add X in front of that, and that's going to be taken up as a non-standard property.
And there's no registration authority for this.
So it's kind of the Wild Wild West, right?
You can maybe add like X, I want to start an app.
And if your client is able to look for that property, and it passes that property, that's
good for you, right?
It's just not going to be compatible with other clients that don't support that property.
And it's not going to be compatible with other clients that don't support that property.
And in the bad old days when the Office applications were fighting for dominance, I think Microsoft
went ham with this.
So this was a really interesting custom property that I saw with Microsoft Office.
They had this auto start check property, custom property, and they also had the collaborate
doc property.
And what the auto start check property did was that when it's time for the event, it's
going to automatically start the video conferencing app, right?
And the collaborate doc property, it just opens.
Okay.
So you can use any file when it's time to start the conference.
So this was interesting, but it's no longer supported in more recent versions of Outlook.
So I had to perform a bit of necromancy, right?
I had to find Windows XP, get Office 2003, and it did work as described, right?
An attacker would send an invitation of an ICS file with these properties set, and immediately
trigger opening any file, even a remote loaded file on the video conferencing app.
I was really happy with that.
And you might see why there's a problem today, because when we have Zoom or some other video
conferencing applications today, that's a huge concern.
You don't want a Randall to send you a calendar attachment, and somehow suddenly your Zoom
pops up, and you start talking to them, or they start listening to you, right?
But this goes to show that even back then there were different considerations for the
properties that companies were creating, and this led to some issues.
So yeah, you're saying, okay, that's all in the past.
That's all dated.
history right but we still have zombie properties coming up and they still exist because i know
there's stuff like backward compatibility the difficulty of dealing with legacy code
makes it difficult to fully excise some of these old properties so microsoft does have another
property called mws url meeting workspace url and meeting workspaces if you've used office in
maybe like five ten years ago maybe have been a bigger thing but basically it's kind of a previous
iteration of the meetings stuff that microsoft did nowadays we have teams you have skype but this
was something that happened back then and this had really interesting behavior because when you have
this property existing in your event and you respond to the event what it's going to do is
going to take that url and it's going to send a soap message to that and depending on how we
respond the applications are also going to behave in pretty strange ways so so that's something you
can look at as well another thing is that it is going to show this
in the ur in the gui as a view meeting workspace button and if you have kind of played around with
outlook in the past or office applications you would know that microsoft actually
sanitizes a lot of custom uris it does this automatically it pops up an alert if you're
going to click that saying oh it's not http or something like that but this was able to kind
of bypass the check i guess because it was much older code in the code base unfortunately this
was like two months before for lena so i wasn't able to use that for the full chain
but this is another example of where it would be really nice if you guys told me your custom uri
exploits that would be really helpful okay so that's microsoft apple google patented their
custom property google patented a way to iframe widgets in your calendars so some of you guys
might have used calendar classic you might have used uh google homepage back in the day and that
was really fun you know adding random widgets to your home page um and what google wanted to do
was that they wanted people to have a way to have a word of the day in their calendar or maybe
you know who's famous which famous person's birthday is it today because people like that
and when you can see from the graphic over there that's what it's supposed to look like
it's basically an iframe in your calendar
and how that works in the background is that it is another custom property called x google calendar
content and that means you can load remote content you can load a image as well as an iframe url
in today's context that's also a bad thing right when you receive an email
most of the time these days the clients are not going to load the remote content immediately
because that's a privacy concern we think about tracking pixels we think about de-anonymization
but this was not the case for this and also when it comes to iframes iframes are also an issue
because when you want to securely display an iframe these days you most of the time you're going to
put them in a sandbox to disable scripts stuff like that but google doesn't do that so while
you're in the google calendar you can do that and you can see that the calendar doesn't exist
today google calendar classic doesn't exist today classics never die there's still parts of google
calendar that still use this that still display this i think they patch this but this is on
google embedded calendar and various parts of the google you're going to find this pop-up and it's
going to work and that's great because say for example if you're going to view the calendar
you're going to want to make sure that you have the content for you right and that's going to be
an issue as well because end users are not going to be aware of what's actually happening and as
i mentioned earlier you can load this all fully remotely without user interaction
one interesting thing that apple is also doing custom properties is that it's actually jerry
rigging its own data structures onto iCalendar so while browsing say one of my scheduled events
flight events on my iCalendar i noticed a couple of things i noticed x apple
properties one of which is the pipe delimited format that added a bit more rich information
to my event but also notice x apple structured data and that was basically a base64 string
that decoded into the binary property list format so for those of you who are more
familiar with mac os internals that is basically a proprietary apple format that can be decoded
further into the property list format and the property list format can be decoded further into
mac os right so you have four layers of abstraction four layers of passing and four layers of
decoding in iCalendar that is pretty interesting and if you look at it the xml basically contains
your flight reservation information and there are some interesting things you could do to
tweak what's displayed on the calendar but basically this also is supported remotely so if
you're going to send someone a calendar invite and contains all of these properties that's also going
to be rendered in the in the application
and this leads to a lot of problems so i haven't dug too deep into this but i would definitely
fuzz this a lot more given given the the various layers of passing and i would definitely
recommend that people look at this and next i'm going to talk about interactions with smtp and
caldev so given that the apple calendar iCalendar format has all of these these properties it
doesn't actually work in a vacuum so as i mentioned earlier when you accept an
invitation on say outlook or another application what it really does is that your client is going
to send an email with an ics attachment via whichever protocol it uses most of the time it's
going to smtp but maybe if you're doing on a web app it's going to have its own custom api call to
http and it's going to send it to the organizer property and the organizer is going to pass that
in their server it's going to update their own calendar invitation and it's going to send it out
to all the other invites
so that they know who is attending this event so my good friend indy when i was discussing this with
him he's really has done some good work in the mailbox space you might wonder what happens to
that organizer property right so for that property it's going to be an email and it's
going to paste that in an smtp conversation smtp commands basically have a new line delimited kind
of commands it's kind of like a ftp session if you think about it
it starts with the handshake it starts with mail from and it's going to paste that organizer
property value into the receipt to command so who that email is going to go to and inti had this
great suggestion he said how about new lines when i went when i heard that i was like yeah how about
new lines because if you deal with protocols and and formats this is kind of this first thing you
kind of look out for and it's true because you can craft a rfc compliant email address with new
lines and this allows you to inject basically new smtp commands so instead of just when a person
a victim kind of accepts the invitation instead of sending an email to the organizer or so they
think what's going to happen is that you can inject their own smtp email so they can send
an email somewhere else they might forge an email on your behalf and so on so thanks inti
that was a nice one and the impact of this really depends on the smtp server support i guess because
some of them do have soft failure modes some of them do have additional commands that you can use
but generally speaking when it comes to smtp injection you can modify say the sender the
receiver the contents of your email and this can lead to some pretty interesting
or terrible interactions with with your victim another interesting protocol that
icalendar interacts with is caldev so caldev is a superset of webdev which is itself a superset of
smtp and if you if you intercept the request from your iphone or maybe your mac os you're actually
going to see a lot of this because apple still uses caldev to sync uh calendar objects between
your phone and its servers the icloud servers and it's really kind of a legacy format because
it was used back in the day again when the syncing between servers wasn't proprietary and people
wanted to make it work maybe you might have one email client from yahoo mail and you want to sync
it with your outlook mail right so all of them use caldev and this is kind of a legacy format because
they're using caldev uh back then and companies didn't like that they don't want things to be
compatible nowadays because you know they have market power google tried to deprecate it i think
about five years ago and basically the developers kind of rose up and complained about it so they
said okay we won't deprecate it we'll try it next year so in the documentation they've been
saying they're going to deprecate it for a couple years now hasn't really been totally phased out
but it's still there microsoft itself if you're familiar with azure and
stuff they work with the graph the new graph protocol and that basically creates objects
using json but they still use caldev in some of their back their backward compatibility with
clients lock suite is an application created by byte dance and they do have support for caldev
but it's read only i think mostly because they use their own proprietary apis to update
events but they use the read-only caldev in order to have compatibility with different mail clients
so when you look at it caldev just provides you with additional way to inject your properties
when it came to say google it was a bit difficult for me to bypass say the http api to inject some
of my payloads into a calendar object but when i used the caldef protocol i was able to just inject
it without much problems so if you're working with caldef and you're working with iCalendar you
might also want to consider using caldef as a way to deliver your payloads without having to deal
some kind of proprietary api or file format and that was something that was really interesting to
me yeah so so that kind of sums up the uh number of the bugs that i put out there and um you might
want to think what's going what can you do as a user or a creator a developer of the iCalendar
format so in my opinion it seems like what vendors are doing is that the evolution of iCalendar is
going to be more jerry rigging right what we see here with microsoft is a kind of a
bridge between the iCalendar format and their graph api so basically it's a json nested in
iCalendar and that's basically another type and that's basically another key value format embedded
within another key value format a lot of these companies are doing this they're basically adding
their own ways of passing a special templates special encoding that's being put in the value
format so it's no longer just a pure raw text format but you can see again how this is an
interesting uh
attack vector because once you have these additional passing you can also do
pretty interesting injections depending on what's going on back then
and you might also think how can you secure this right given that you have so many clients from so
many different platforms and frameworks and for microsoft what they've done is they've created
their own internal passing standards they call it the iCalendar to appointment object conversion
algorithm and it basically is a standard way for them to pass these from iCalendar into
calendar or event object and this is i think
not a bad way to do things especially if you have a huge number of clients and most of your
customers are going to be using the clients anywhere not kind of bridging between different
clients another option is to contribute to open passing standards and this is something that
i would recommend people do i know the apple's engineer has pushed out a couple of rfcs in this
front but this helps to secure things across the entire ecosystem and because i think the rfc
not yet complete, there's still a lot of things missing
in how you're passing or dealing with the iCalendar format
that needs security considerations,
especially since it was written in 1998 and 2009.
There are a lot of things that are missing
in terms of modern privacy and security standards.
Now of course, I think, as a developer,
you want to stay frugal with non-standard behavior, right?
Back in the early 2000s, companies went wild
with custom properties because they love widgets,
they love all of these kind of shiny extras.
But what I've seen is also that a lot of these things
are really hard to get out of your system
once you support it, right?
Because you need to have backward compatibility,
you also need to have some of your legacy code
that might be hard to excise.
And this, I think Google was a kind of case in point,
because it might not exist in modern Google Calendar,
but it still exists in other parts of the website
that other people can still access, and it's not ideal.
And so for researchers,
there's still a lot more properties to research.
I have an open source database right now
for some of these properties.
I've only put up a couple right now,
but I think tomorrow I'm gonna put up the rest.
I would really appreciate any contributions to this
as we dive into our calendar standard,
especially since for the end users themselves,
they might not be aware what's going on behind the scenes,
and that's always a concern, right?
Because it's doing all these flashy stuff.
It's not always compatible.
Most of it is not compatible.
Most of it is gonna break when you move between standards,
and a lot of it is not documented.
So I think it really helps to kind of document
some of these custom properties,
whether if you're a builder or a breaker,
that's gonna help us out a lot.
So yeah, that's my URL,
and hopefully you can see some contributions.
So thank you very much.
I really appreciate your attention.
I have some, thank you.
Thank you.