The IMF Conference is the International Conference on IT Security Incident Management & IT Forensics. This year it took place from May 23 to 24 in Munich. The schedule lists a lot of interesting talks. One of the talks was my presentation on a paper about Ceph forensics, based on my Master Thesis:
In this blog post, we are sharing summaries of talks from the Hack in the Box Conference in Amsterdam (HITBSecConf2023), the final HITB conference in Amsterdam. Before we do that, however, we would like to extend a heartfelt thank you to the organizers of the conference for putting together such an insightful and engaging event.
I am going to disclose two bug classes I found a while ago in CheckPoint R77.30: Two buffer overflows in the username (no shit) and HTTP method of a request to the administrative UI pre-auth and some interesting injections into the TCL web interface.
Process Hollowing is a technique used by various malware families (such as FormBook, TrickBot and Agent Tesla) to hide their malicious code within a benign appearing process. The typical workflow for setting up such a hollowed process is as follows:
Create a new process (victim) using a benign executable, in suspended state.
Unmap the executable from that process.
Allocate memory for the malicious executable at the address of the previously mapped victim executable.
Write the malicious executable to the new memory area and potentially apply relocations.
Adjust the entry point.
We will refer to this as the “normal” Process Hollowing workflow. There are also variants of this technique, one being to not unmap the original executable and to allocate the new memory somewhere else. We will call this one no-unmap. But wait, why does malware not simply overwrite the existing executable but creates a new memory area which stands out due to its characteristics? In this blog post we will have a closer look at this overwrite approach but also on the no-unmap method, their effects on analysis/detection tools and on some tricks to make the detection harder. We are also releasing Proof of Concept implementations of all mentioned tools/plugins (the links are at the end of this post).
Spymax is a mobile Remote Administration Tool (RAT) that enables an attacker to control victims’ devices through an Android malware. Once the malware is installed on a phone, the attacker can execute many attacks that highly impact the confidentiality and integrity of the victim’s data, as well as the victim’s privacy. It is powerful, widely available, and does not require root privileges on the victim’s device. In this blogpost, I show the capabilities of this RAT and analyze how its Android malware works.
Over the course of the last 2 years we performed vulnerability research on several Endpoint Management & Monitoring Solutions. The results were already partially presented in security advisories which were published on this blog during the last two years. The advisories can be found here:
Updated on 20.06.22 with CVEs and link to Broadcom Security Notice.
In April 2021 we reported seven vulnerabilities in Broadcom Automic Automation (UC4) 12.3.5+hf.3. CVE IDs were assigned on 16.06.22, the corresponding Broadcom Security Notice can be found here.
The vulnerabilities have been found in the course of a research project, in which we analyzed the security of multiple Endpoint Management solutions. Similar vulnerabilities have been found in other solutions as we pointed out in previous posts about the Ivanti DSM Suite, Nagios XI, and Solarwinds N-Central. The outcome of the research project will be published as a whitepaper and a conference talk at Troopers 2022.
In this blog post we will provide a short description of the vulnerabilities outlining the impact. More technical details will be published in the whitepaper and conference talk. All vulnerabilities were found in Broadcom Automic Automation (UC4) version 12.3.5+hf.3.
Missing server-side validation consistently scores a place in the OWASP Top 10. Browsers nowadays offer a lot of ways to easily implement client-side controls, increasing the usability by a lot. They automatically detect missing fields or invalid characters in your input fields and may even validate user input against a regular expressions.
However, these controls should only be considered as usability features. When sending data to a back-end system the application must always ensure data integrity by implementing encodings, validations and filters. Even for small applications this is a painful and tedious process. For each possible input, developers together with security experts have to carefully identify the context of each field, how the input is going to be used and what data requirements are present.
Furthermore, the application must always be aware of the current data encoding and apply the correct decoding before validating or filtering anything.
In this post we are going to present a new groundbreaking solution to combat missing server-side validation once and for all.
In my ordinary life, I teach computer science at the University of Applied Sciences in Mannheim but for some months, I was an intern at ERNW learning a lot about IT security and penetration testing. One of these learnings is that old protocols can be fun and breaking them even more. But let’s start at the beginning of the story…
Back in the year 1986: Top Gun, Platoon, and Crocodile Dundee were the top-grossing films in the cinema and IBM sold the very first laptop computer, called IBM PC Convertible (model 5140). The Internet Engineering Task Force (IETF) was just founded and Boris Becker won the Wimbledon Championships for the second time. A group of engineers of the Organisation for Data Exchange by Tele Transmission in Europe (ODETTE) met and specified OFTP, a protocol to transfer files over … no, there was no Internet commercially available at that time … X.25 networks. X.25 itself dates back to 1976 and is a packet-switched protocol for WANs. The OFTP protocol tried to “address the electronic data interchange (EDI) requirements of the European automotive industry” RFC2204, page 3. With the rise of the Internet, OFTP was extended in 1997 to support TCP/IP in addition to X.25 as the transport protocol (RFC2204) and in 2007 again to include encryption and authentication (RFC5024). With RFC5024 we have the most recent specification of the protocol which is called “OFTP2”. They somehow skipped their 10-year cycle (86, 97, 07) and did not release a current specification in the last 14 years.