[TeamT5] Pwn2Own Contest Experience Sharing and Vulnerability Demonstration

Pwn2Own is a renowned hacking competition that focuses on discovering and exploiting vulnerabilities in various software and operating systems. The event provides a platform for cybersecurity researchers and ethical hackers to showcase their skills by attempting to compromise the security of popular software and devices. Organized by the Zero Day Initiative (ZDI), a program from Trend Micro, Pwn2Own has gained prominence for its role in identifying and addressing critical security flaws.

During the competition, participants target a range of software applications, web browsers, operating systems, and other digital platforms. Successful exploitation of a vulnerability typically involves the execution of arbitrary code or the bypassing of security mechanisms. Contestants who successfully compromise a system are awarded cash prizes and may also receive the device they exploited.

Pwn2Own plays a crucial role in improving cybersecurity by incentivizing the discovery and responsible disclosure of security vulnerabilities. The competition not only fosters a competitive spirit among security researchers but also encourages software developers and vendors to enhance the robustness of their products. The insights gained from Pwn2Own contribute to the overall improvement of digital security, making it a significant event in the cybersecurity community.

Since this is more of a test trial for us, and we've been investing a lot of effort in the IoT field lately, we've instinctively selected some targets from the SOHO Smash-up list: one from the Initial Stage and another from the Final Stage. The devices in the Initial Stage are all routers, likely exposed to the Internet for some reason. As for devices in the Final Stage are just regular everyday devices like IP Cameras, NAS, and Printers, etc. Additionally, you'll earn bonus points if you can leverage your exploit to compromise targets all the way from Initial to Final, hence the name.

After selecting our targets, we began evaluating potential attack surfaces. It's worth mentioning that in Pwn2Own, besides the conventional approach of compromising devices directly from the external network (WAN) to gain control, they also entertain the idea of Man-in-the-Middle (MitM) attacks. In other words, if you can find a way for the device to interact with you—say, if the device regularly requests a specific DNS domain or supports a discovery protocol allowing attackers to impersonate a client and interact with it—those approaches are fair game. Alternatively, discussing common device configurations and usage patterns with the organizers is also on the table.

Before the official competition kicks off, there's an online draw organized by the officials to let everyone know when their exploits will be tested. We get a chance to see others' testing schedules and target devices. When you notice someone testing the same target as you, thoughts like, 'Are we going to collide?' or 'If there's no collision, what exploit are they using?' start creeping in. Of course, it's essential to sign an NDA and submit the final whitepaper and vulnerability proof of concept (PoC) a few days before the actual competition.

A few days before the official testing begins, we receive an official communication from Pwn2Own. The email confirms the final test versions for each target device and provides us with the Teams link and guidelines for the upcoming session. On the day of testing, the organizers reach out to ensure we've checked relevant settings on the devices, installed necessary libraries for our exploit, and confirmed language versions. They reiterate the rules for exploit testing: we have three attempting opportunities, each execution must not exceed ten minutes, and the total duration for all three attempts must stay within thirty minutes.

After making sure all the settings are good to go, the organizers initiate the countdown and run the designated exploit script. Even though we've run countless tests in our local environment, the second the organizers launch the process, seeing the screen fill with logging lines brings a rush of tension. The excitement for that elusive root shell grows, making us ponder if it'll truly come to life.

Rahhhhhhhhhh ....!! Get Shell 🤩

Following successful exploitation, the organizers verify with us the root cause of the vulnerability and whether it matches any previously reported issues. If there's a collision in discoveries, the points earned are reduced, and correspondingly, the prize money decreases. With that, the competition concludes, and the final results can be checked on the organizer's X (Twitter) or official website.

A stack-based buffer overflow has been identified in /lib/libjansson.so.4.7.0, a JSON parsing library. This vulnerability stems from a modified JSON dictionary key parsing feature. The library is utilized in parsing configuration files and handling web requests.

The issue arises when encountering an object (JSON dictionary type) key. At this point, a call to sscanf(key, "%s %s", v1, v2) is executed. As both v1 and v2 are local stack array variables, the unrestricted sscanf operation leads to a stack-based buffer overflow when processing malicious JSON input.

Here's the pseudocode of the function containing the bug in libjansson.so.4.7.0:

json_t *parse_object(lex_t *lex, int flags, void *error)
{
    // Stack variables
    char v1[32];
    char v2[12];
    // ...
    char *key;
    json_t *json;
    // ...
    while ( 1 )
    {
        // ...
        if ( memchr(key, 0, len) )
        {
            jsonp_free(key);
            error_set(error, lex, "NUL byte in object key not supported");
            goto error_exit;
        }
        v2[0] = 0
        _isoc99_sscanf(key, "%s %s", v1, v2);
        // ...
    }
    // ...
error_exit:
    json_decref(json);
    return 0;
}

This vulnerability could be leveraged to achieve remote code execution with a crafted request to the device by an attacker. Furthermore, it has been addressed and fixed in the latest version, as indicated in the release notes of BC500. Therefore, we strongly recommend that you update your device as soon as possible for your own security

This is our first time technically attempting the Pwn2Own contest. Essentially, everything is new to us, including how to sign up for the event, submit our findings along with reports to the organizers, and, of course, negotiating with the organizers or vendor about whether the vulnerabilities we submitted have been duplicated by other participants.

Even though everything was new to us, diving into this challenge turned out to be quite intriguing. From the team spirit during the competition to the suspense when the organizers hit 'enter,' it all added to the excitement.

The organizers were really cool too. As we waited for the testing, they struck up some casual conversation with us, throwing questions like, "Can we expect some fancy logging as output?" or "How about outputs like memory leaks?" It was a simple chat, but it instantly took the edge off our nerves.

Our experience in the Pwn2Own competition was quite an adventure. Looking ahead to our next shot, we aim to come even more prepared, unveiling more 0-days, and, of course, some fancy logging for sure. Until the next Pwn2Own, catch you later!