Last year, the CISO of a customer sent me a laptop for analysis. The reason was that he feared the company could have been victim of industrial espionage. Starting in spring 2020, the IT help desk got several employee laptops with full hard drives, caused by a huge amount of audio recordings. The audio files contained recordings even of highly sensitive telephone conferences. An automated scan on all employee computers for such audio recordings showed that about 300 devices were affected. Continue reading “Of Corona, Buggy Audio Drivers and Industrial Espionage”
In this post, I will introduce fpicker. Fpicker is a Frida-based coverage-guided, mostly in-process, blackbox fuzzing suite. Its most significant feature is the AFL++ proxy mode which enables blackbox in-process fuzzing with AFL++ on platforms supported by Frida. In practice, this means that fpicker enables fuzzing binary-only targets with AFL++ on potentially any system that is supported by Frida. For example, it allows fuzzing a user-space application on the iOS operating system, such as the Bluetooth daemon bluetoothd – which was part of the original motivation to implement fpicker. Continue reading “fpicker: Fuzzing with Frida”
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.
Anti-Virus Software
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 12.3.0.670 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 12.3.0.670.
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.