Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03350.jsonl.gz/2018

One of our minions (he was introduced in this blog entry a while ago) recently came to us asking for advice: he was about to automate yet another task, by using his Python-fu, and realized that he misses entries in the file system as well as in the registry.
Notably, he only sees this behaviour on 64bit-versions of the Windows operating system:
The left image shows the folder C:\Windows\System32\Tasks as seen in the Windows Explorer, the right image as seen in a simple 32bit-python application. Only the subfolder Microsoft is listed there. Something is amiss.
Below is the code to produce the right image, when executed in a 32bit-version of Python:
import glob, os
for pathfilename in glob.glob(r"C:\Windows\System32\Tasks\*"):
print pathfilename
ENISA Cyber Security Exercise: More than 400 Cyber security professionals from 29 countries and 200 organisations are involved in a biannual cyber exercise coordinated by the European Union Agency for Network and Information Security (ENISA).
Die Digitale Gesellschaft Schweiz hat ihren Swiss Lawful Intercept Report 2014 veröffentlicht. Dieser dokumentiert die Überwachungsaktivitäten der Kantone und des Dienstes Überwachung Post- und Fernmeldeverkehr (ÜPF).
The ICC Belgium published a 72-page Cyber Security Guide including a Security Self Assessment Questionnaire.
Have you heard about the Security Bloggers Network? It’s the largest collection of information security focused blogs and podcasts in the world with almost 300 different blogs and podcasts included. They offer one feed of all the sites. (Sub-feeds for specified categories are in the works.)
Win32/Sefnit: Despite you are not using Tor maybe your computer does. This blogpost from Microsoft explains how the Tor client service, added by Sefnit, is posing a risk to millions of machines. What you’ll learn also: Microsoft has the ability to remotely remove programs en masse from people’s computers.
In einem aktuellen Internet-Draft (draft-ietf-opsec-vpn-leakages-02) beschreibt Fernando Gont Gefahren, die von VPN-Software ausgeht, welche nicht IPv6-fähig ist. Eine Zusammenfassung:
Führen Organisationen IPv6 auf ihren Client-Systemen ein, ist die bevorzugte Strategie in der Regel die, dass IPv6-Konnektivität zusätzlich zur bestehenden IPv4-Anbindung hergestellt wird (“Dual Stack”). Wenn diese Clients sich nun per VPN mit dem nächsten Office-Standort verbinden, sei es z.B. vom Home-Office oder Kunden aus, dann sollte die Verbindung über diese VPN-Schicht für eine verschlüsselte Datenübertragung sorgen.
Das Problem ist nun, dass heute nicht alle VPN-Clients IPv6-fähig und für das Dual-Stack-Szenario gerüstet sind. Sie kennen vereinfacht gesagt kein IPv6. Wenn nun eine VPN-Verbindung aufgebaut wird, kümmern sich diese VPN-Clients wie gewohnt um den IPv4-Traffic, z.B. indem sie die Default Route ändern um den Traffic in den VPN-Tunnel zu leiten. IPv6-Traffic wird aber weiterhin über die normalen IPv6-Routen geleitet und bleibt damit von der VPN-Verschlüsselung ausgenommen. Integrität und Vertraulichkeit der möglicherweise sensiblen Daten ist dadurch nicht mehr gewährleistet.
Als der Amerikaner Phil Zimmermann 1991 die erste Version seines Programms ‘Pretty good Privacy’ (PGP) herausbrachte, war es sein Ziel, dass Bürger und Bürgerbewegungen, sei es in den USA oder ausserhalb, Nachrichten so austauschen können, dass diese sicher vor dem Zugriff durch Geheimdienste sind.
Mehr als 20 Jahre später ist dies nun durch PRISM und Co. mehr denn je zu einem aktuellem Thema geworden.
Damals – 1991 – herrschten Exportbeschränkungen für Kryptosysteme mit einer Schlüssellänge von mehr als 40 Bit. Daher wurde der PGP-Programmcode nach einigem Hin und Her 1995 als über 900 Seiten starkes Buch herausgegeben (“PGP Source Code and Internals”), womit der Export legal wurde. Jenseits der US-amerikanischen Grenzen machten sich dann Dutzende Freiwille daran, den Quellcode aus dem Buch wieder abzutippen und zum lauffähigen Programm zu kompilieren. Continue reading “Pretty bad Privacy – Wer nicht verschlüsselt…”
1. Operativen Betrieb absichern – IPv6 ist bereits da!
Als aller erstes sollten Sie das latente Risiko durch existierende Dual-Stack-Rechner in Ihrer IT-Umgebung einschätzen: Alle modernen Betriebssysteme sind IPv6-enabled und können mittels Autokonfiguration “von aussen” konfiguriert werden. Damit stehen einem potenziellen Angreifer einige IPv6-spezifische Attacken zur Verfügung, ohne dass Sie jemals IPv6 bewusst konfiguriert und ausgerollt haben. Auf den Systemen wird durch die Autokonfiguration ausserdem “eine zweite Tür geöffnet”, für die bestehende Sicherungsmechanismen (beispielsweise IP-basierende ACLs) unter Umständen nicht greifen. Continue reading “IPv6 für (Security-)Manager – Teil 4: Loslegen, aber sicher!”
Werden autoritative DNS-Server über reflektierende DNS-Angriffe missbraucht, zum Beispiel um in einem Distributed Denial of Service (DDoS) Angriff ein Zielsystem zu überlasten, so ist eine der vorgeschlagenen Massnahmen DNS Response Rate Limiting (DNS RRL) zu aktivieren.
SWITCH hat auf diesem Blog bereits in früheren Posts über DNS Angriffe und Massnahmen berichtet. In diesem Artikel möchten wir unsere neusten Beobachtungen im Betrieb von DNS RRL teilen und zeigen, dass es Anzeichen gibt, dass die Angreifer die Schwächen von DNS RRL ausnutzen um weiterhin ihre Angriffe durchführen zu können.
Stärken und Schwächen von DNS RRL
Für viele autoritative DNS Serverbetreiber war DNS RRL eine ersehnte Lösung um die Serverlast und vor allem die ausgehende Serverbandbreite aufgrund von reflektierenden DNS-Angriffen einzuschränken. DNS RRL lässt für einen IP-Adressbereich nur eine bestimmte Anzahl identische DNS Antworten zu. Wird der konfigurierte Schwellwert überschritten, verwirft DNS RRL zum einen die DNS-Antwort. Für einen anderen Teil der Antworten wird das “Truncated”-Bit (TC) in der Antwort gesetzt, damit wird der DNS Resolver aufgefordert, die Anfrage noch einmal über TCP zu stellen. Da bei reflektierenden DNS-Angriffen die Quelladresse gefälscht wird, kommt nie eine Verbindung über TCP zu Stande. Im Gegensatz zu Firewall-Regeln hat der DNS RRL Ansatz den Vorteil, dass bei einem leicht geänderten Angriffs-Pattern (z.B. Query-Name ändert) die implementierten Firewall-Regeln nicht angepasst werden müssen. Kurz, DNS RRL ist sehr effektiv gegenüber Angriffen, bei denen DNS-Anfragen gesendet werden, welche in identischen Antworten resultierten. Continue reading “Was kommt nach DNS Response Rate Limiting?”
DDoS: To provide insights on the latest DDoS threats – and effective mitigation strategies – Information Security Media Group has launched a DDoS Resource Center.
Windows 7 Reinstall-How-to: Your PC has become infected with malware? You don’t know how to correctly reinstall your system, and reduce the risk of becoming reinfected at the same time? Have a look at the new How-to from EBAS. (Available in 4 languages.)
Surfing the web is like walking London in 1886. Usually you meet nice and lovely Dr. Jekyll, interact with him, and all fine, cosy and perfect. But in other circumstances, during the night, you might hit on evil and malicious Mr. Hyde. He just wants your money and your secrets, or abuse you. As in the novel by Stevenson, the good and the bad web pages can be very close together. Continue reading “Jekyll or Hyde? Better browse securely”
Im Rahmen einer neuen Tech-Event-Reihe, die das Swiss IPv6 Council in Kooperation mit Digicomp durchführt, hatte ich am vergangenen Montag die Gelegenheit, das Thema “IPv6 Security und Hacking” vorzustellen. Mit rund 70 Teilnehmern stiess auch diese zweite Veranstaltung der Reihe auf reges Interesse.