Last month, the Centre for Strategic Infocomm Technologies (CSIT) invited local cybersecurity enthusiasts to tackle the InfoSecurity Challenge (TISC). The Challenge was organized in a capture-the-flag format, with 6 cybersecurity and programming challenges of increasing difficulty unlocked one after another.

I recently participated in FireEye’s seventh annual Flare-On Challenge, a reverse engineering and malware analysis Capture The Flag (CTF) competition. Out of the 11 challenges ranging from typical executables to games written in exotic programming languages, I liked Challenge 7 the best.

GovTech’s Cyber Security Group recently organised the STACK the Flags Cybersecurity Capture-the-Flag (CTF) competition from 4th to 6th December 2020. For the web domain, my team wanted to build challenges that addressed real-world issues we have encountered during penetration testing of government web applications and commercial off-the-shelf products.

Late last year, I was invited to Facebook’s Bountycon event, which is an invitation-only application security conference with a live-hacking segment. Although participants could submit vulnerabilities for any Facebook asset, Facebook invited us to focus on Facebook Gaming. Having previously tested Facebook’s assets, I knew it was going to be a tough challenge.

Overall, I felt that the OSEP was worth the price of admission given the sheer amount of content it throws at you, as well as the excellent labs that will solidify your learning-by-doing. Here’s my review along with some tips and tricks to maximize your OSEP experience.

The Peach protocol fuzzer was a well-known protocol fuzzer whose parent company – Peach Tech – was acquired by GitLab in 2020. This article aims to demonstrate an end-to-end application of Peach Fuzzer, from build to deployment.

After clearing the OSEP at the end of February 2021, I took the 60-day EXP-301/OSED package from March to May 2021, and finally cleared the exam in mid-June. At the time of writing, this costs $1299. As my job role is pretty multi-disciplinary, I found it necessary to build up my exploit development skills and the OSED came at a right time.

Most research into the malicious applications of AI tends to focus on human factors (scamming, phishing, disinformation). There has been some discussion of AI-powered malware but this remains very much in the proof-of-concept stage. This is partly a function of the kinds of models available to researchers - generative models lend themselves easily to synthetic media, while language models are easily applied to phishing and fake news. But where do we go from these low-hanging fruits?

This two-part series will share how I got started in vulnerability research by discovering and exploiting code execution zero-days in office applications used by hundreds of millions of people. I will outline my approach to getting started in vulnerability research including dumb fuzzing, coverage-guided fuzzing, reverse engineering, and source code review. I will also discuss some management aspects of vulnerability research such as CVE assignment and responsible disclosure.

By searching for DBF-related vulnerabilities in Microsoft’s desktop database engines, I took one step towards the deep end of the fuzzing pool. I could no longer rely on source code review and dumb fuzzing; this time, I applied black-box coverage-based fuzzing with a dash of reverse engineering. My colleague Hui Yi has written several fantastic articles on fuzzing with WinAFL and DynamoRIO; I hope this article provides a practical application of those techniques to real vulnerabilities.

From 29 October to 14 November 2021, the Centre for Strategic Infocomm Technologies (CSIT) ran The InfoSecurity Challenge (TISC), an individual competition consisting of 10 levels that tested participants’ cybersecurity and programming skills. I took away important lessons for both CTFs and day-to-day red teaming that I hope others will find useful as well. What distinguished TISC from typical CTFs was its dual emphasis on hacking AND programming - rather than exploiting a single vulnerability, I often needed to automate exploits thousands of times. You’ll see what I mean soon.

Wishing you and your loved ones a very happy new year!

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.

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.

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.

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.

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.

When is copy-paste payloads not self-XSS? When it’s stored XSS. Recently, I reviewed a Zoom’s code to uncover an interesting attack vector.

One common perception is that it is easier to write rules for Semgrep than CodeQL. Having worked extensively with both of these static code analysis tools for about a year, I have some thoughts.

The Offensive Security Exploitation Expert (OSEE) certification is a legendary apex achievement among OffSec’s offerings - unabashedly featuring a skull logo and grim reaper iconography in previous iterations. Here’s how I tackled it while busy at work.

Have you ever wondered how display monitor software can change various settings like brightness over a simple display cable? As it turns out, this relies on a standard protocol that can lead to interesting vulnerabilities. Here’s how I found and exploited CVE-2023-5449 in dozens of HP display monitors.

It’s always interesting to find edge cases in strong appsec programmes like Meta and Google that have generally solved entire bug classes like cross-site scripting because it highlights potential blind spots in appsec strategy. In particular, I’m still fascinated by the Clipboard API that seems to evade typical static analysis tools, like a stored XSS I found in Zoom Whiteboard. Here’s how I found similar bugs in Excalidraw (used in Messenger and other Meta assets) and Microsoft Whiteboard.