I am glad to announce the release of the ERNW whitepaper 71 containing information about quarantine file formats of different AV software vendors. It is available here.
I took quarantine files from real-life incidents and created some in a lab environment. Afterwards I tried to identify metadata, like timestamps, path names, malware names, and the actual malicious file in the quarantine files. One goal was to use this information to support our incident analyses: Using the results, we can now easily create timelines showing information about quarantined files, extract the detected malware, and sometimes even find information about processes that created the malicious files. Continue reading “ERNW Whitepaper 71 – Analysis of Anti-Virus Software Quarantine Files”
It’s Friday, you managed to escape for a couple of hours from a busy working day to see a doctor. Now you have to wait in a boring waiting room at the clinic until it’s your turn to see her majesty. What would you like to do in this time? Answer pending business emails, get lost in social media, or choose a new theme to make your iPhone look awesome? What about: all of the above? It’s nice to have everything on your iPhone: MDM enrollment to access business data, in addition to jailbreak for device freedom. However, MDM solutions ban jailbroken devices, because they are not secure enough to handle sensitive business data. And so, cat and mouse games of jailbreak detection/bypass between MDM solutions and some users develop.
In this blogpost, I highlight how this cat and mouse game with Google’s MDM solution “Google Endpoint Management” is currently going. First, I explain how to bypass jailbreak detection of Google’s MDM solution. Then I show how to manipulate MDM enforced policies on your MDM-enrolled jailbroken device. Since these actions have negative impacts on your device’s security, we’ll also discuss how attackers can exploit this insecure setup to steal business data.
With this blog post, I will provide information on how to proceed when testing ELK Stack landscapes. Information regarding the exploitation of the ELK Stack is very rare on the internet. Therefore, following article aims to provide you with some approaches that can be useful during a penetration test. Continue reading “Pentesting the ELK Stack”
In the last blog post, we discussed how fuzzers determine the uniqueness of a crash. In this blog post, we discuss how we can manually triage a crash and determine the root cause. As an example, we use a heap-based buffer overflow I found in GNU readline 8.1 rc2, which has been fixed in the newest release. We use GDB and rr for time-travel debugging to determine the root cause of the bug.
In August 2020 we reported six vulnerabilities in SolarWinds N-Central 188.8.131.520 to the vendor.
The following CVE IDs were assigned to the issues :
CVE-2020-25617: RCE in N-Central Administration Console (AdvancedScripts Endpoint)
CVE-2020-25618: Local Privilege Escalation from nable User to root (N-Central Backend Server)
CVE-2020-25619: Access to Internal Services through SSH Port Forwarding (N-Central Backend Server)
CVE-2020-25620: SolarWinds Support Account with Default Credentials
CVE-2020-25621: Local Database does not require Authentication (N-Central Backend Server)
CVE-2020-25622: CSRF in N-Central Administration Console (AdvancedScripts Endpoint)
The vulnerabilities have been found in the course of an extensive research project, in which we analyze the security of multiple Unified Endpoint Management (UEM) solutions. Similar vulnerabilities have been found in other solutions as we pointed out in previous posts about the Ivanti DSM Suite and Nagios XI. The final outcome of the research project will be published as a whitepaper and possibly conference talk as soon as the project including all disclosure processes concludes.
We will provide a short description of the CVEs outlining the impact of the vulnerabilities. Technical details will be published in a whitepaper as mentioned above. All six vulnerabilities have been verified for SolarWinds N-Central 184.108.40.2060.
This blogpost sheds some light on how fuzzers handle crash deduplication and what a unique crash is for a fuzzer. For this, we take a look at two contrived examples and compare the unique crashes identified by AFL++ and honggfuzz.
Recently, I had a brief look at the Froala WYSIWYG HTML Editor (v3.2.0) as there was a post about it on the Full Disclosure mailing list.
When targeting a HTML Editor, I guess one of the first things that everybody does is to check for XSS vulnerabilities. So I tried the usual XSS payloads (a great resource for XSS payloads is the XSS cheat sheet by PortSwigger) within the editor’s code view, but did not have much luck with the common payloads as they were filtered. However, using the HTML object tag, it was possible to trigger an XSS.
Microsoft has released a set of privacy settings for Office, one of which enables users to configure the type and amount of diagnostic (i.e., telemetry) data that Office may send to Microsoft. When deployed, it is available in the form of a group policy setting. It allows users to configure one of the following diagnostic data levels: required, optional, or neither. The report we produced:
analyzes the impact of the required, optional, and neither diagnostic data levels on the output of diagnostic data produced by Office; and
provides and evaluates approaches for partially or fully disabling the output of diagnostic data produced by Office.
I have started to have a look at my local installed helpers on macOS. These helpers are used as an interface for applications to perform privileged operations on the system. Thus, it is quite a nice attack surface to search for Local Privilege Escalations.
Forklift is an advanced dual pane file manager for macOS. It is well known under macOS power users.
As part of my investigation I identified vulnerabilities in Forklift allowing local privilege escalation.
Some time ago, we carried out an evaluation of the Digital Health Applications Ordinance (Digitale-Gesundheitsanwendungen-Verordnung, DiGAV) for the Federal Chamber of Psychotherapists in Germany (Bundespsychotherapeutenkammer, BPtK) focusing on the security of digital health applications, often referred to as apps on prescription.
The audit was intended to determine to which extent security guidelines, security objectives, and best practices are adhered to by the requirements formulated by the ordinance, thus enabling the foundations to securely operate digital health applications. The main subject of the examination is whether requirements, including procedural requirements defined in the ordinance are sufficient to ensure security of digital health applications. The examination has shown that the requirements can be seen as positive. However, in order to be able to make reliable statements about the IT security of digital healthcare applications, further details and mechanisms should be clarified within the ordinance, which I would like to present in the following.