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…
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.
Using a static passkey for Bluetooth Low Energy pairing is insecure. Recent
versions of the Bluetooth specification contain an explicit warning about this.
However, in practice, we often see static passkeys being used. Moreover, there
are no public implementations of proofs-of-concept that can practically show why
using a static passkey is an issue. This is why we implemented one.
In a recent assessment, we were testing a device that offered a Bluetooth
interface for data export and configuration. This device uses Bluetooth Low
Energy (BLE), and a static passkey (or PIN) is required to pair with it. This
passkey is displayed for a few seconds when the device is booted and stays the
same on each reboot. In fact, it is derived from static, device-specific data.
The Federal Office for Information Security (BSI) aims to sensitize
manufacturers and the public regarding security risks of networked medical
devices in Germany. In response to the often fatal security reports and press
releases of networked medical devices, the BSI initiated the project
Manipulation of Medical Devices (ManiMed) in 2019. In this project, a security
analysis of selected products is carried out through security assessments
followed by Coordinated Vulnerability Diclosure (CVD) processes. The project
report was published on December 31, 2020, and can be accessed on the BSI
website
[1].
I recently stumbled upon a strange behavior in my Firefox: I visited an
HTTPS-enabled website that I had visited before and saw that my Firefox
connected insecurely via HTTP. I found that strange because nowadays, most
websites set the
HSTS
header, which is supposed to force the browser to connect via HTTPS. I checked
whether this website set the HSTS header – and it did. This means my Firefox was
ignoring/forgetting about the HSTS header right after my visit.
In this post, we are discussing a bug we came across in Mesas llvmpipe Gallium3D
graphics driver. This bug was accessible through Chromium’s WebGL implementation
and can provide control of the program counter (pc) within Chromium’s GPU
process if llvmpipe is used. Llvmpipe is a software rasterizer that is used on
Linux if no hardware acceleration (graphics card) is available. This is a pretty
rare edge case as llvmpipe has no widespread use. An estimate by Google is that
approx 0.06% of the Chromium users are affected by this. However, as this is a
simple but valid Chromium bug, we want to give you a quick walkthrough. The
issue is tracked as
CVE-2021-21153
and was fixed in February 2020.
BloodHound data collection, aka Sharphound, is quite a complex beast.
When giving BloodHound workshops, the part where I get the most questions is
always data collection.
How is the BloodHound data collected? What methods do what? Who am I talking
to? How do I fly under the radar?
These are all very relevant questions when you think about it.
After all, the rest is just a gorgeous UI sitting on top of a cool data model,
but the only bit of BloodHound code that ever touches the targeted network is
SharpHound. And so questions about it should be mandatory.
Now even thought I’ve been working with BloodHound for quite a while, there is
always this moment where I have to check before answering… (I feel the older I
get, the quicker I understand, but the less I remember… but that’s another story
I guess…)
Wir freuen uns, dass das Bundesamt für Sicherheit in der Informationstechnik
(BSI) im Rahmen des gemeinsam mit ERNW durchgeführten SiSyPHuS Win10-Projekts
(Studie zu Systemintegrität, Protokollierung, Härtung
und Sicherheitsfunktionen in Windows 10) heute (ca. 10 Uhr) die nächsten
drei Arbeitspakete veröffentlicht:
Empfehlung zur Härtung von Windows 10 mit Bordmitteln
Empfehlung zur Konfiguration der Protokollierung in Windows 10
Gruppenrichtlinien zu den Konfigurationsempfehlungen für Härtung und
Protokollierung für Windows 10
In den Dokumenten finden sich unterschiedliche Empfehlungen für
Domänenmitglieder (mit normalem und mit hohem Schutzbedarf) und
Einzelplatzrechner. Die Dokumente bauen auf den Empfehlungen von Microsofts
Security Baseline und dem CIS Benchmark für Windows 10 auf und ergänzen diese in
von Microsoft und CIS nicht betrachteten Bereichen oder modifizieren sie dort,
wo es aus Erfahrung von ERNW im Hardening von Windows-Systemen sinnvoll ist.
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.
The training
Software-Defined Radio applied to security assessments
was held by Sébastien Dudek at Troopers21 and was remotely organized – like most
other events – due to Covid-19. Once we were all caffeinated, we had an exciting
journey through basically all things radio.
We started with the technical and physical basics in radio technology, such as
various sorts of antennas, analog to digital coding (and backward), encoding
schemes, and general risks and possible vulnerabilities of using radio devices.
Commonly found vulnerabilities include the following: