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.
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…
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.
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.
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.
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.