 Hello, and welcome to the 3 o'clock Track 3 talk. You have one new opponent, hacking proprietary IACalendar properties by Eugene Lim. Before we begin, I have two announcements. Number one, please wear your masks 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. Thank you so much for coming. I know it's day two of DEF CON, so you guys have survived. 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 IACalendar properties. And before I begin, I just want to give a quick introduction to myself. I'm Eugene, and I go by Spaceracoon Online. That's my Twitter handle, because someone has a Twitter handle for Spaceracoon. So if you are that guy, come up to me. We can work something out after this. You know, I can't pay much, but we'll figure something out. I work at the cybersecurity 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 an appointment reminder in the last week or so? Maybe a ping, a mobile notification. Yeah, most of you guys do, because especially in the COVID, post-COVID, well, 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 checking out an application, an 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 might have started. So 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 an Apple format because you might think iPhone, iPad. But the iCalendar format is actually the name for a standardized format defined by RSC. There's interoperable between various email and calendar clients from Microsoft Outlook to Google Calendar to Apple Calendar. And 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 what I was 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 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 NextCloud 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 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 RFC 2445, which is the Internet Calendar Object Specification, was first published by two guys, Dawson 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 shared between various office applications. And back in 1998, the context was that it was a huge office wars because all of these companies were coming out with their own office suites. 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 be able to accept, to invite, and attend it. But if you're all using different formats, that's not going to work out. 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 plan they have for today. I'm going to give you a background to the iCalendar format, some interesting things that might have came up in my research and 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 led 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 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 protocol interactions, because 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 that's all kind of things that add additional complexity to using iCalendar and has led to vulnerabilities. And I'll give some 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 2445RFC that was way back in 1998, and it was kind of superseded by what is 5545, which was in 2009, done by someone from Oracle. And more recently, we have seen also a couple more updates. The most recent one also from Apple, engineer from Apple. But you also have a bunch of other RFCs 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 IRC 5545, 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 IRC. So what actually goes on in a calendar? 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, common delimited and new line delimited. And it's a bit similar to, say, XML, because there are some opening and closing texts. 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 time start, the end, the location, the URL. And these are all standard properties that 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 gonna 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 gonna 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're 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 Skype 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 a team's meeting URL. And that's gonna 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. 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 an event for you, right? And a lot of these data is actually gonna be 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 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 across the notification way, so it's just gonna 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 system. So when it's time for the event, it's gonna 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 a HTTP server and a remote server. And we can see why that might be an issue today because you could play something nasty or dangerous and you don't want that to be loading remote content without your consent. 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 you 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 IRC, they have kind of noted these dangers by default stuff. They've kind of deprecated it. But there's still insecure implementations of standard IRC properties. And I'll go 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, they stuck to the specification. They interpret that as plain text. But Google and VMware, they actually interpret this as HTML. 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 or your inbox, right? And it's going to be added as a non-blocking event until you respond to it. But it's going to be that. And because of that, you can trigger a payload remotely without any user interaction. Depending on, of course, 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 versions in order to get 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, right? 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 client. So if you're gonna look at that on your mobile phone or in macOS, 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 macOS. So this will 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 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 looked 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're going 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 non-standard 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 gonna 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 icloud folder and you can also upload that and that's gonna 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 if you wanna 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 gonna talk about today. I love it when companies do things differently because then 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 wanna add your own functionality, you wanna 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 gonna be taken up as a non-standard property and there's no registration authority for this. So it's kind of the Wawa 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 gonna 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 CollaborateDoc property. And what the auto start check property did was that when it's time for the event, it's gonna automatically start the video conferencing app, right? And the CollaborateDoc property, it just opens 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? A attacker would send an invitation of ICS file with these properties set and immediately trigger opening any file, even a remote loaded file on the victim's desktop. And you might see why that'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 render 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 dead history, right? But we still have zombie properties coming up and they still exist because 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, 10 years ago, maybe have been a bigger thing, but basically it's kind of a previous iteration of the meeting stuff that Microsoft did. Nowadays we have Teams, we have Skype, but this was something that happened back then. And this had really interesting behaviour because when you have this property existing in your event and you respond to the event, what it's gonna do is gonna take that URL and it's gonna send a SOAP message to that and depending on how we respond, the application's also gonna behave in pretty strange ways. So that's something you can look at as well. Another thing is that it's gonna show this in the GUI as a View Meeting Workspace button and if you've 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 in the alert if you're gonna click that, saying oh, it's not HTP 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 Fulina, so I wasn't able to use that for the full chain, but this is another example of where it'll 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 Google Homepage back in the day and that was really fun, adding random widgets to your homepage. 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 whose 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 image as well as an iframe URL. And 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 gonna load the remote content immediately because that is 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 wanna securely display an iframe these days, most of the time you're gonna put them in a sandbox to disable scripts, stuff like that, but Google doesn't do that. So while Google Classic doesn't exist today, Google Calendar Classic doesn't exist today, classics never die. There are still parts of Google Calendar that still use this, that still display this. I think they're patched this, but this is on Google Embedded Calendar. And various parts of the Google, you're gonna find this pop-up and it's gonna work. And that's great because say for example, if you're gonna view the calendar, that's gonna pop some dynamic scripts or content for you, right? And that's gonna be an issue as well because end users are not gonna 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 with custom properties is that it's actually gerry-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 I also noticed X-Apple structured data. And that was basically a base-64 string that decoded into the binary property list format. So for those of you who are more familiar with macOS 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 XML, right? So you have four layers of abstraction, four layers of parsing, 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 were 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 gonna send someone a calendar invite and it contains all of these properties, that's also gonna be rendered in their application. And this leads to a lot of problems. So I've been dug too deep into this, but I would definitely fuzz this a lot more given the various layers of parsing. And I would definitely recommend that people look at this. And next, I'm gonna talk about interactions with SMTP and CalDef. So given that the iCalendar format has all of 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 gonna SMTP, but maybe if you're doing it on a web app, it's gonna have its own custom API call to HTTP. And it's gonna send it to the organizer property. And the organizer is gonna parse that in their server. It's gonna update their own calendar invitation and it's gonna send it out to all of 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. So for that property, it's gonna be an email and it's gonna 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 a mail from and it's gonna paste that organizer property value into the receipt to command. So who that email is gonna go to. And Indy had this great suggestion. He said, how about new lines? When I heard that, I was like, yeah, how about new lines? Because if you deal with protocols 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 victim kind of accepts the invitation, instead of sending an email to the organizer, or so they think, what's gonna 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 Indy, 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 a soft failure mode, 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 your victim. Another interesting protocol that iCalendar interacts with is CalDef. So CalDef is a superset of WebDef, which is itself a superset of HTTP. And if you intercept the request from your iPhone or maybe your Mac OS, you're actually gonna see a lot of this because Apple still uses CalDef to sync 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 wanna sync it with your Outlook Mail, right? So all of them use CalDef back then. And companies didn't like that. They don't want things to be compatible nowadays because 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 gonna 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 CalDef in some of their back, their backward compatibility with clients. LockSuite is an application created by ByteDance and they do have support for CalDef, but it's read-only. I think mostly because they use their own proprietary APIs to update events, but they use the read-only CalDef in order to have compatibility with different mail clients. So when you look at it, CalDef 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, their 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 with the hassle of some kind of proprietary API or file format. And that was something that was really interesting to me. Yeah, so that kind of sums up the number of the bugs that I've put out there. And you might want to think 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 gonna be more Jerry Waking, right? What we see here with Microsoft is 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 Vortex format. But you can see again, how this is an interesting 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 a 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 gonna be using the clients anyway, 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 IRFCs in this front. But this helps to kind of secure things across the entire ecosystem. And because I think the IRFC for calendar, iCalendar, is 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 wanna stay frugal with non-standard behavior, right? Back in the early 2000s, companies went wild with custom properties because they love widgets, we 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 exercise. And I think Google was a kind of case in point because it might not exist in a 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 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 breaker, that's gonna help us out a lot. So yeah, that's my URL and hopefully I can see some contributions. So thank you very much. I really appreciate your attention. I have some, thank you.