Although I do not actively participate in CTFs, I enjoy creating challenges for them as it forces me to learn by doing. Creating a good CTF challenge is an art, not a science. As the winner of last year’s $30k The InfoSecurity Challenge (TISC), I decided to contribute a challenge instead this year.

Countless applications rely on Amazon Web Services’ Simple Notification Service for application-to-application communication such as webhooks and callbacks. To verify the authenticity of these messages, these projects use certificate-based signature validation based on the SigningCertURL value. Unfortunately, a loophole in official AWS SDKs allowed attackers to forge messages to all SNS HTTP subscribers.

First defined in 1998, the iCalendar standard remains ubiquitous in enterprise software. However, it did not account for modern security concerns and allowed vendors to create proprietary extensions that expanded the format’s attack surface. I demonstrate how flawed RFC implementations led to vulnerabilities in popular enterprise applications. Attackers can trigger exploits remotely with zero user interaction due to automatic parsing of event invitations. Furthermore, I explain how iCalendar’s integrations with the SMTP and CalDAV protocols enable multi-stage attacks. Despite attempts to secure these technologies separately, the interactions that arise from features such as emailed event reminders require a “full-stack” approach to calendar security. I conclude that developers should strengthen existing iCalendar standards in both design and implementation.

While browsing a SharePoint instance recently, I came across an interesting URL. The page itself displayed a web form that submitted data to SharePoint. Intrigued by the .xsn extension, I downloaded the file and started investigating what turned out to be Microsoft InfoPath’s template format. Along the way, I discovered parts of the specification that enabled loading remote payloads, bypassing warning dialogs, and other interesting behaviour.

DOM-based Cross-site scripting (XSS) vulnerabilities rank as one of my favourite vulnerabilities to exploit. It’s a bit like solving a puzzle; sometimes you get a corner piece like $.html(), other times you have to rely on trial-and-error. I recently encountered two interesting postMessage DOM XSS vulnerabilities in bug bounty programs that scratched my puzzle-solving itch.