Last year our team had to analyze V8 bytecode. Back then, there were no tools in place to decompile such code and facilitate convenient navigation over it. We decided to try writing a processor module for the Ghidra framework. Thanks to the features of the language used to describe the output instructions, we obtained not only a readable set of instructions, but also a C-like decompiler. This article is a continuation of the series (1, 2) on our Ghidra plugin.
Several months went by between writing the processor module and this article. In this time, the SLEIGH specification remained unchanged, and the described module works on versions 9.1.2 – 9.2.2, which have been released during the last six months.
On ghidra.re and in the documentation distributed with Ghidra there is a fairly good description of the capabilities of the language. These materials are worth reading before writing your own modules. Preexisting processor modules by the framework’s developers might be excellent examples, especially if you know their architecture.
You can see in the documentation that the processor modules for Ghidra are written in SLEIGH, a language derived from the Specification Language for Encoding and Decoding (SLED), which was developed specifically for Ghidra. It translates machine code into p-code (the intermediate language that Ghidra uses to build decompiled code). As a language for describing processor instructions, it has a lot of limitations, although they can be reduced with the p-code injection mechanism implemented as Java code.
The source code of the new processor module is presented on github. This article will review the key concepts that are used in the development of the processor module using pure SLEIGH, with certain instructions as examples. Working with the constant pool, p-code injections, analyzer, and loader will be or have already been reviewed in other articles. Also you can read more about analyzers and loaders in The Ghidra Book: The Definitive Guide.
Have you ever wanted to find out how a program you often use, a game you play a lot, or the firmware of some realtime device actually works? If so, what you need is a disassembler. Better still, a decompiler. While things are pretty clear with x86–x64, Java, and Python, as there are plenty of disassemblers and decompilers to go around, with other languages, the situation is a little bit more complicated, and search engines will simply tell you ‘it can’t be done.’
It’s common knowledge that in 2019 the NSA decided to open source its reverse engineering framework known as Ghidra. Due to its versatility, it quickly became popular among security researchers. This article is one of many to come dedicated to covering the technical details of the ghidra_nodejs plugin for Ghidra, developed by our team. The plugin’s main job is to parse, disassemble and decompile NodeJS Bytenode (.jsc) binaries. The focus of this article is the V8 bytecode and the relevant source code entities. A brief description of the plugin is also provided, which will be expanded upon in greater detail in subsequent articles.
Our team searched for bugs in the source code of Cockpit, an open-source content management system. Here is the description of Cockpit from its official site:
Cockpit is a headless CMS with an API-first approach that puts content first. It is designed to simplify the process of publication by separating content management from content consumption on the client side.
Cockpit is focusing just on the back-end work to manage content. Rather than worry about delivery of content through pages, its goal is to provide structured content across different channels via a simple API.
While investigating the Cockpit source code, we discovered numerous vulnerabilities. Attackers could exploit them to take control of any user account and perform remote code execution.
In this article, I will talk about the technical details and demonstrate how these vulnerabilities can be exploited.
Since the PoC for the VMware vCenter RCE (CVE-2021-21972) is now readily available, we’re publishing our article covering all of the technical details.
In fall of 2020, I discovered couple vulnerabilities in the vSphere Client component of VMware vCenter. These vulnerabilities allowed non-authorized clients to execute arbitrary commands and send requests on behalf of the targeted server via various protocols:
Unauthorized file upload leading to remote code execution (RCE) (CVE-2021- 21972)
An unauthorized server-side request forgery (SSRF) vulnerabilities (CVE-2021-21973)
In this article, I will cover how I discovered the VMware vSphere client RCE vulnerability, divulge the technical details, and explain how it can be exploited on various platforms.
Palo Alto Networks next-generation firewall (NGFW) is one of the leading enterprise firewalls used by companies around the world to protect against various cyber-attacks. It runs on its own operating system «PAN-OS».
In this article, we will analyze the vulnerabilities that lead to:
This August, I discovered three vulnerabilities in McAfee ePolicy Orchestrator (ePO) version 5.10.0. McAfee ePO is software that helps IT administrators unify security management across endpoints, networks, data, and compliance solutions from McAfee and third-party solutions. McAfee ePO provides flexible automated management capabilities for identifying, handling, and responding to security issues and threats.
My testing uncovered three vulnerabilities:
A CSRF + SSRF + MITM chain that, if successfully exploited, allows an attacker who is not logged in to perform remote code execution on the server
Remote code execution by a logged-in user as the result of a ZipSlip attack
Today we will be analysing multiple vulnerabilities that we found in a component of Checkpoint Security Management, which is used in Check Point products. The component in question is the ICA Management Tool.
Citrix Endpoint Management, aka XenMobile, is used for managing employee mobile devices and mobile applications. Usually it is deployed on the network perimeter and has access to the internal network due to Active Directory integration. This makes XenMobile a prime target for security research.
During such research a path traversal vulnerability was discovered. This vulnerability allowed an unauthorized user to read arbitrary files, including configuration files containing passwords.