After seven years, we’re publishing a new macOS hardening guide. Fully updated,
modernized, and now publicly available on
GitHub
as
Markdown
and on our website as
PDF.
The previous guide, written for macOS Mojave (10.14), reflected a very different
macOS security model. At the time, hardening often meant working around the
operating system, manually enforcing controls, and compensating for missing
platform guarantees. That guide served its purpose, but the platform has
fundamentally changed since then.
The purpose of this blog post is to explain how Secure Boot works. In
particular, we will explain where current implementations of Secure Boot by
Linux distributors fall short compared to Microsoft Windows and Apple macOS.
Major distributors like Canonical, Debian, openSUSE, and Red Hat place a high
priority on making their operating systems work out of the box. Given the
current Linux landscape with out-of-tree drivers and incompatible licenses,
providing the end user with all the drivers possibly needed to boot the system
can be challenging.
Many Linux hardening guides focus on well-known protections: full-disk
encryption, Secure Boot, and password-protected bootloaders. While these
measures are critical, they often overlook a subtle but serious attack vector:
the ability to drop into a debug shell via the Initial RAM Filesystem
(initramfs). This oversight can enable an attacker with brief physical access to
bypass conventional boot protections and inject persistent malware into the
system.
In this post, it is demonstrated how this attack works on modern Linux
distributions, such as Ubuntu and Fedora, and explained why existing guidance
often fails to mention it.
When you’re analyzing web applications as a pentester or reading pentest reports
about web applications, you will often see findings regarding cookies missing
certain security flags. The Set-Cookie HTTP header and the JavaScript
document.cookie API allow to use, for example, the
flags Secure, Path, and Domain.
Common audit and pentest tools will tell you when your web application does not
or just insecurely implements these cookie flags.
However, they do not provide optimal security even when using these flags
correctly. However, there are mitigations available that partly solve the
issues.
For the realization and introduction of autonomous vehicles, the safe interaction of functions, systems and services as well as their monitoring over the entire product life cycle is essential. An exclusive security-by-design approach is no longer sufficient and must be continuously supported by feedback obtained from in-the-wild operation. This is where the recently successfully completed joint project BMBF UNCOVER comes into play, which targets the requirements of the standards ISO/SAE 21434 (Road vehicles – Cybersecurity engineering) and ISO 21448 (Road vehicles – Safety of the intended functionality (SOTIF)).
In 2021, ERNW collaborated with
Hochschule Mannheim for their CEP (Cyber Security
Entwicklungsprojekt) to build an auditing framework for testing operating system
configurations against security procedures. This project is part of the
education program of the university to give the students the chance to utilize
the knowledge gained throughout the first semesters in a real world project.
ERNW posed as the fictitious customer, providing a requirements document and
regular meetings with all project groups for feedback. We planned to process and
adapt the results for an open source auditing framework. Unfortunately, we were
not able to finish this project yet, but we think the students should get some
attention for their work independent from our side. So here is a short summary
of what the students created and the corresponding repositories.
I’m happy to announce the
release of several plugins for
Volatility 3 that allow you to dig deeper into the memory analysis. One of those
plugins is PteMalfind, which is essentially an improved version of malfind.
Another one is PteResolve which, similarly to the WinDBG command !pte,
allows you to inspect Page Table Entry (PTE) information for e.g., a given
virtual address. In this blog post we will have a closer look at these and more
plugins, and the PteEnumerator base class and what you can do with it. The
memory dump used for this blog post is available
here. Some of
the injection tools used in this blog post can be gathered from
here.
With this blog post I am pleased to announce the publication of a new ERNW White Paper about the HL7 FHIR communication standard.
Introduction
Digital networking is already widespread in many areas of life. More and more medical devices are also being networked in the healthcare industry. This growth makes the development and use of new medical communication standards necessary since existing solutions can only meet the changing requirements with great effort. The HL7 FHIR standard is an example of such a medical communication standard. FHIR is said to have increased the interoperability between different medical contexts,e.g., administration, billing, and clinical care, to enable data exchange of various systems. The FHIR standard addresses the security risks associated with strongly networked communication from a large number of systems across the trust and organizational boundaries only indirectly because FHIR does not define mandatory security controls or requirements.
TLDR: This blogpost presents devi, a tool that can help you devirtualize virtual calls in C++ binaries. It uses Frida to trace the execution of a binary and uncover the call sources and destinations of virtual calls. The collected information can then be viewed in IDA Pro, Binary Ninja, or Ghidra. The plugin adds the respective control-flow edges allowing further analysis (using different plugins) or simply providing more comfort when analyzing C++ binaries.
Arrroooo… Bloodhound Crew!! Heard the news? CypherDog 4.0 is out and it’s full of new features…
Now a couple of you might be thinking “Hey there, wait a minute… didn’t CypherDog 3.0 come out not that long ago..??”, and I am happy to see some of you are paying attention…
Indeed, when Bloodhound 3 came out, I quickly updated CypherDog 2 to CypherDog 3 to be compatible with it.
But Bloodhound 3 is compatible with neo4j 3 and 4, however the neo4j REST API has been deprecated in neo4j 4 and CypherDog 3 relied on it.
Long story short, CypherDog 4.0 is a full rewrite compatible with the new neo4j 4 HTTP API, and since I was refactoring the whole thing, I added some cool new features to the tool.
The idea was to be able to do more with less keystrokes, and to do it server-side…
And so I made a meme.