Nvidia: 2 Sicherheitslücken im Linux-Treiber

Zwei Sicherheitslücken sind im NVIDIA GFX-Kartentreiber für Linux enthalten, wenn Ihr noch nicht die brandaktuellste Version haben solltet, was schwierig sein dürfte.

Nvidia: 2 Sicherheitslücken im Linux-Treiber

Laut der Bugbeschreibung bei Nvidia, handelt sich dabei bei einer Lücke um einen Bug in der IPC Communication API, was man braucht um Daten zwischen einzelnen Prozessen hin und her zu schicken. Dieser Fehler kann dazu genutzt werden um mit erweiterten Rechten eingeschleusten Code auszuführen.

CVE-IDs
Addressed
Software ProductOperating SystemDriver BranchAffected VersionsUpdated Versions
CVE‑2020‑5963
CVE‑2020‑5967
GeForceLinuxR450All versions prior to 450.51450.51
Quadro, NVSLinuxR450All versions prior to 450.51450.51
R440All versions prior to 440.100440.100
R390All versions prior to 390.138390.138
TeslaLinuxR450All R450 versionsAvailable the week of June 29, 2020
R440All versions prior to 440.95.01440.95.01
R418All versions prior to 418.152.00418.152.00

Die zweite Schwachstelle ist dann schon schwieriger auszunutzen, da eine RACE Condition ist, es kämpfen also zwei Prozesse um eine Ressource. Der Gewinn des RACE würde einen DOS erlauben. Was ein Angreifer auf einem DesktopPC davon haben würde die Grafikkarte zu crashen, naja. Ist trotzdem gut, daß es gefixt wurde.

Für Fedora lautet die Treiberversion für meine GFX-Karte 440.82 und muß daher aktualisiert werden. Da diese aus dem Repo von RPMFusion stammt, dürfte der Verbreitungsgrad und damit der Updatezwang unter Fedora/Centos/RHEL Benutzern entsprechend hoch sein. Wie das zu Problemen führen kann und was man das machen muß, lest Ihr hier: Nvidia, Fedora, RPMFusion und der Bug, der nicht sein soll.

Bei RPMFusion habe ich heute schon angeklopft, daß Updates benötigt werden.

Quelle: https://nvidia.custhelp.com/app/answers/detail/a_id/5031

Security: Angriff auf WPA2 möglich, wenn Broadcom&Cypress Chips im Spiel sind

Eine Meldung der Hacker News erfreut die Gemütslage von allen Admins weltweit: WPA2 + Broadcomships sind eine schlechte Kombination 🙁

Angriff auf WPA2 möglich, wenn Broadcom & Cypress Chips im Spiel sind

Die mit CVE-2019-15126 registrierte Schwachstelle mit dem Namen „Kr00k“ erlaubt es in Kombination mit dafür anfälligen Chips von Broadcom &  Crypress, die WLAN Verschlüsselung teilweise zu verhindern.

Das funktioiert so, daß ein Angreifer ohne überhaupt im Funktnetz zu sein, ständig Disassoziationen auszulöst, indem er Deauthentifizierungspakete an alle sendet. Das führt dazu, daß sich die Chips aus dem WLAN lösen und den WLAN Schlüssel intern auf NULL setzen. So weit wärs noch ok, aber nun senden anfällig Broadcom und Crypress Chips die Restpufferinhalt im Chipspeicher ohne die Verschlüsselung ans Ziel. Streng genommen verschlüsseln die die Daten mit 000000000000000000, was dann keine Verschlüsselung mehr ist. Ist also ein Bug in der Chipfirmware, weil die müßte den Puffer auch leeren, statt den Inhalt denn zu senden.

„Unsere Tests bestätigten, dass einige Client-Geräte von Amazon (Echo, Kindle), Apple (iPhone, iPad, MacBook), Google (Nexus), Samsung (Galaxy), Raspberry (Pi 3), Xiaomi (RedMi) sowie einige Zugangspunkte von Asus und Huawei für Kr00k anfällig sind“, so die ESET-Forscher.“ schreiben die Hacker News.

Diese Lücke hackt also nicht Eurer WLAN Passwort, weswegen ein Wechsel des Passworts nichts bringt. Da Broadcom Chips in allen möglichen Geräten zu finden sind und damit in allem was IoT, Accesspoints, alte Handies etc. ist ungepatcht laufen, wird das ein schöner Mitschmatsch werden.

Wie könnt Ihr euch schützen?

Das schlimmste was mit dem Angriff passiert ist, daß einige eurer Pakete im WLAN so übertragen werden, als wenn es ein OFFENES-WLAN wäre. Damit sind alle die Datenübertragungen betroffen, die Klartextverbindungen beinhalten, z.b. HTTP:// Traffic, FTP, SMTP, POP, IMAP, DNS und jede Menge IoT Geraffel. Wer seine Dienste alle mit TLS Verbindungen wie HTTPS, FTPS, SFTP, SCP, SSH, STARTTLS für SMTP, POP und IMAP schützt, muß sich keine Sorgen machen. Aber wer zu Hause intern von einem PC per Samba auf einen anderen PC zugreift, dessen Daten könnten damit abgelauscht werden.

Ein gezielter Angriff auf bestimmte Daten ist mit dem Angriff nicht möglich, der Angreifer weiß also nie was er da so bekommt, aber je mehr er mitschneidet, desto schlechter für Euch.

Wie bekomme ich raus, daß ich betroffen bin?

Für Eurer Linux braucht Ihr erstmal eine Version von „lshw„, also für Fedorabenutzer eingeben: „sudo dnf install -y lshw

Ihr werdet Rootrechte brauchen, also „sudo su“ eingeben. Mit „ip l“ bekommt Ihr Eure Interfacenamen heraus, „ifconfig“ würde es auch tun:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp2s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000
link/ether f0:76:1c:be:39:c8 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 34:e6:ad:5d:18:ee brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:e7:5f:07 brd ff:ff:ff:ff:ff:ff

Wir brauchen das wlp3s0 WIFI Interface. Jetzt gebt Ihr „lshw | less“ ein und bekommt eine lange Liste mit Info zu Eurer Hardware. Den Befehl solltet Ihr Euch also merken, den braucht man häufiger mal. In der Ausgabe sucht Ihr nach Eurem Interfacenamen und stoßt so auf solch einen Block:

*-network
description: Wireless interface
product: Wireless 3160
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:03:00.0
logical name: wlp3s0
version: 83
serial: 34:e6:ad:5d:18:ee
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=5.2.18-100.fc29.x86_64 firmware=17.3216344376.0 ip=192.168.0.103 latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:54 memory:c4000000-c4001fff

Entweder verrät es euch jetzt schon die Herstellerbezeichnung, hier Intel Corporation, oder der Drivername (hier iwlwifi) gibt den Chiphersteller preis. Wenn da BC drin vorkommt, war es ein Broadcom. Den Code für Crypress Chips kenne ich jetzt leider nicht auswendig, aber das findet Ihr vermutlich im Netz auf Linux-Wifi-Infoseiten.

Wie gehts weiter?

Apple soll wohl bereits Patches für seine Benutzer veröffentlicht haben. Wann die anderen patchbaren Systeme hinterher ziehen, bleibt offen. Für alles was IoT, oder mehr als 2 Jahre alte Accesspoints, Handies etc. kommt wohl jede Hilfe zu spät, da hilft nur entsorgen. Vorher würde ich aber einen Blick auf die Webseite meines Herstellers werfen, vielleicht gabs ja doch ein Gnadenupdate.

Quelle: https://thehackernews.com/2020/02/kr00k-wifi-encryption-flaw.html

Exim: neue mögliche RCE Schwachstelle gefunden

Toller Sonntag. Überall Regen und dann weckt mich noch die Meldung, das im Exim eine neue, nicht abwehrbare Schwachstelle gefunden wurde 🙁 ( wichtiges 13 Uhr Update unten )

Elysium ist gefallen

Es gibt einen neuen Bug, der auch bereits gefixt wurde, aber leider nicht mit einem Workaround abzuwehren geht. Das bedeutet für Euch, daß Ihr Updaten müßt.

Der Fehler liegt in einem Programmierfehler der Stringverarbeitung, die dummerweise bereits beim HELO/EHLO greift. Ein Angreifer kann einen Heap-overflow auslösen, in dem er einen überlangen ELHO String sendet.

An der Stelle des Codes wurden die Rootrechte zwar schon gedroppt, aber das hilft nur wenig, falls der Angreifer tatsächlich einen RCE hinbekommt, was nicht ausdrücklich ausgeschlossen ist, aber auch nicht 100% bestätigt wurde. Daher muß man davon ausgehen, daß es jemand früher oder später schafft: Worst-Case halt.

Betroffen sind alle Versionen < 4.92.3.

Also entweder Ihr patchted Euren alten Exim selbst, oder Ihr updated auf die neue Version. Eure Entscheidung.

Aktuelle CVE Nummer zu dem Exim RCE : CVE-2019-16928 .
(Passage geändert, vorher keine bekannt gewesen.)

13 Uhr Update

Fedora kompilierte Versionen sind nicht angreifbar. Der Exploit funktioniert einfach nicht.

Getestet auf: Fedora 29 64Bit gegen 4.92.2

Andere Distros könnten angreifbar sein. Es hängt auch ein bisschen damit zusammen, wie das angegriffene System konfiguriert ist. „Eylsium ist gefallen“ ziehe ich damit teilweise zurück .. das Fedosium steht noch :DDD

Der Exploitstring ist übrigens 11k lang, nur falls Ihr das bei euch mal selbst ausprobieren wollt, nehmt gleich 12k.

Außerdem wurde mitgeteilt, daß es im Rahmen der 4.92.x eingeführt wurde und mit 4.93 auch schon wieder draußen war. Die Exploitmeldung war leider etwas hastig formuliert worden. Allerdings sehe ich da keinen Schaden drin, weil „besser safe than sorry“ wie der Denglischer sagt 😉

 

KDE-Desktop: RCE Schwachstelle durch .desktop Dateien

Wie die Hacker News heute morgen berichten, ist im KDE 4/5 Plasma Desktop eine Schwachstelle enthalten, die durch das reine Herunterladen von manipulierten Desktopdateien ( erkennbar an den Endungen .desktop und .directory)  ausgelöst werden kann.

Schwachstelle im KDE Desktop Indexer für Plasma

Die Ursache liegt im unsicheren Indexer, der neue Dateien analysiert und für die Suchfunktion des Desktops aufbereitet.

Dabei werden Umgebungsvariablen aus der analysierten Datei übernommen, was dazu führt, daß ein Angreifer seinen Schadcode ausführen kann. Auch das Auspacken von Archiven triggert den Indexer an, so daß auch dies die Schwachstelle auslöst.

Securityforscher Dominik Penner, der die Lücke direkt an die Hacker News geschickt hat, statt sie dem KDE Security Team zu senden, schreibt dazu:

„When a .desktop or .directory file is instantiated, it unsafely evaluates environment variables and shell expansions using KConfigPrivate::expandString() via the KConfigGroup::readEntry() function,“ Penner said.

„Wenn eine .desktop oder .directory Datei instanziiert wird ( A.d.R.: muß wohl gelesen heißen ), werden auf unsichere Weise Umgebungsvariablen und Shellerweiterungen ausgewertet, in dem die Funktion KConfigPrivate::expandString() via KConfigGroup::readEntry() genutzt wird“ schreibt Penner.

Diese Schwachstelle erinnert extrem stark an die kürzlich gefundenen Schwachstellen in Exim, wo auch die  Inhalte von fremdeingelieferten Strings ausgewertet werden und zu einem Root-Exploit eskalieren.

Bis auf weiteres muß man bei Downloads und dem Auspacken von aus unbekannten/unsicheren Quellen stammenden Archiven extrem vorsichtig sein. Das KDE Team hat einen Patch angekündigt, fertig ist der aber noch nicht.

Wenn ich mich recht entsinne, hatte der Gnome Index auch kürzlich erst so eine Schwachstelle.

Kleines Update: (10:24 Uhr)

Es gibt ein Youtube Video, daß das Problem zeigt. Allerdings wird man als unbedarft neugieriger erstmal unverständlich davor sitzen. Daher möchte ich dazu eine kleine Einleitung geben:

In dem Shellfenster rechts startet Penner „nc -lp 31337“  ( 31337 = „elite“ in L33T-Speak 🙂 ). nc startet also einen Dämon und wartet auf Verbindungen. Plötzlich wird nc beendet und wirft eine Fehlermeldung aus. Das liegt daran, daß das Desktopfile, daß per Firefox runtergeladen wird, sich bzw. ein dadurch gestartetes anderes Programm zu besagtem Port 31337 verbindet.

Das zusammen demonstriert das Problem. Man kann in den Desktopdateien natürlich auch „rm -rf /“ unterbringen, oder den Download von Illegalem Filmmaterial starten.

 

Exim CVE-2019-13917 – Die Katze ist aus dem Sack

Ich habe es geahnt, natürlich war die String-Expansion vom letzten Exim Exploit nicht nur dort im Einsatz, sondern auch an anderer Stelle:

CVE-2019-13917 – Root Access für lokale und entfernte Benutzer.

Betroffen sind alle aktuellen(und nicht mehr ganz so aktuellen) Exim Versionen 4.85 -> 4.92.

Laut Jeremy Harris besteht die Lücke wie schon beim letzten Exim Exploit in einer String-Expansion-Operation.

Wir erinnern uns: Ein Angreifer konnte vor einem Monat „<${run{bash}}@zieldomain.de>“ als Absender oder Empfänger einer Email setzen und hatte freien Zugang zum System.

So geht das jetzt auch wieder. Diesmal ist es die „Sort“-Funktion, die Einträge, naja, sortiert halt. Wenn ein Angreifer dort Einträge beisteueren kann, wie z.b. einen modifizierten Received-Header, oder multiple Empfängernamen und der angegriffene Server sortiert diese Einträge, für was auch immer er das bräuchte, dann würde der Text des Angreifers ausgeführt.

In PHP nennt man das die EVAL()-Falle. Ist halt immer blöd, wenn man ungeprüft Sachen von fremden Leuten ausführt 😉

Seid Ihr betroffen?

Das ist leicht festzustellen:

exim -bP config | grep -i sort

als Root ausführen und wenn da nichts kommt, dann seid ihr sicher. Da es in der Default Konfig nicht vorkommt, würde sich ein betroffener Admin jetzt direkt daran erinnern, daß er da was sortiert hat und könnte jetzt Updaten. „Könnte“ weil Fedora User nicht können, in der Rebuildversion von heute liest man leider nur das :

* Thu Jul 25 2019 Fedora Release Engineering <releng@fedoraproject.org> – 4.92-9
– Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

Von CVE liest man nichts, oder Ihr vielleicht? Das ist jetzt peinlich, weil die Exim-Devs das allen Distros rechtzeitig mitgeteilt haben.

Workaround:

Sort-Funktion auskommentieren, siehts zwar nicht mehr schön aus, ist aber sicher 😉

 

 

PHP 5.6/7.x Remote Execution Schwachstelle

Zeit zum Updaten: PHP eine Remote Code Execution Schwachstelle hat!

Risikostufe 4 – Remote Code Execution

Das BSI schreibt im Advisory:

„Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in PHP ausnutzen, um Informationen offenzulegen, einen Denial of Service herbeizuführen oder Code mit den Privilegien des angegriffenen Dienstes zur Ausführung zu bringen.“

betrifft:

Open Source PHP < 5.6.40
Ooen Source PHP < 7.1.26
Open Source PHP < 7.2.14
Open Source PHP < 7.3.1

GPG Pluginschwachstellen

Was bekommt man, wenn man von einer tollen Sicherheitslücke liest, ein lustiges Bild sieht und einen Bug im Grafikprogramm meldet ?

Selbstgemachtes GPG Schwachstellen Logo 🙂

Na ist doch klar, nur Platz #3 in der Reihenfolge der Websites, die über die Schwachstelle berichten 😀

Kurzfassung

Deswegen auch jetzt nur die Kurzfassung: Außer der EFF und dem ForscherSebastian Schinzelaus Münster, weiß noch keiner, was die gefunden haben. Sie empfehlen aber trotzdem die Plugins für Thinderbird & Co. zu entfernen.

Ich vermute, daß man eine Email bauen kann, die den Plugins Kryptoanweisungen unterjubelt, welche die Ausführen  und an den Absender zurück schicken. Ansonsten müßte man ja nicht davor warnen, daß die installiert sind. Vor GPG/PGP an sich, wird ja nicht gewarnt, nur davor die Plugins zu benutzen. Die Autoren müssen auch alles Code aus der gleichen Quelle geklaut haben, weil sonst nicht AppleMail, Outlook und Thunderbird gleichermaßen betroffen wären.

Aber bislang ist das reine Spekulation. Warten wir auf mehr…

Upates: (12:08)

Und da haben wir auch schon den ersten Collateralschaden:

http://www.tagesschau.de/inland/e-mail-verschluesselung-101.html

Die Tageschauredakteure haben die Meldung komplett auf Links gedreht und verbreiten grade, daß die Verschlüsselung gekackt wurde. Leider VERKACKT Leute 😀 Nicht die Verschlüsselung wurde geknackt, sondern die Plugins sind ausnutzbar um auf die verschlüsselten Emails zuzugreifen. Das genau sollen die zwar können, aber nicht, wie ich annehme, fremdbestimmt 😉

Wahrheit: 0  Collateral: 1

Upates: (14:04)

Die Katze ist aus dem Sack. Die Plugins in den Emailprogrammen dekodieren eingebettete Ciphertexte in HTML Emails und leiten die dekodierten Inhalte via HTML Bildlink zu einem eigenen Server aus.
War ja klar, daß die Krypto nicht das Problem sein konnte.

Voraussetzung für so einen Angriff ist aber, daß der Angreifer den verschlüsselten Text einer an das Opfer gesendeten Email hat. Alles-Überwacher wie die NSA haben sowas natürlich auf Lager liegen.

… und so gings weiter …. EFail: Die Katze ist aus dem Sack

 

Bundeshack – Lernplattform Ilias mit Sicherheitslücke

Wie wir ja alle erfahren haben, wurde das Außenministerium über einen Hack bei der Bundeswehr erfolgreich angegriffen.

E-Learning als Einfallstor

Wie sich jetzt rausgestellt hat, war es wohl eine Schwachstelle der E-Learning Plattform Ilias . Das DNF-Cert hat heute eine entsprechende Mitteilung zu Ilias veröffentlicht, in der vor dieser RXSS Lücke und noch unentdeckten anderen gewarnt wird, da nicht klar ist, ob es diese Lücke war, die genutzt wurde.

Betroffen davon sind folgende Versionen:

ILIAS < 5.1.24
ILIAS < 5.2.13
ILIAS < 5.3.1

Das CERT spricht zu Recht an, daß wegen der medialen Aufmerksamkeit, alle Scriptkidis nach verwundbaren Illias Installationen suchen werden. Das bedeutet für alle Illias Betreiber, daß Sie Ihre alten Installationen updaten sollten, um die zu erwartenden Angriffe abwehren können.

Quellen:

https://www.golem.de/news/government-hack-hack-on-german-government-via-e-learning-software-ilias-1803-133231.html

„DFN-CERT-2018-0466 ILIAS: Eine Schwachstelle ermöglicht einen Cross-Site-Scripting-Angriff [Linux][Apple][Windows]“

Ethereum – Eclipse Sicherheitslücke behoben

Über solche Meldungen im Bezug auf „Geld“ freut man sich immer:

„Developers of Ethereum, the world’s No. 2 digital currency by market capitalization, have closed a serious security hole that allowed virtually anyone with an Internet connection to manipulate individual users‘ access to the publicly accessible ledger.“

bedeutet, wenn man verhindert, daß sich ein Miner zum Netz verbindet, und er so nur Verbindungen zu Servern von Angreifern aufbauen kann, kann ihm eine geänderte Blockchain untergejubelt und er dazu gebracht werden, daß er u.a. Transaktionen doppelt signiert ( was wie bei BitCoin der eigentliche Job ist ).

Der Eclipse Angriff

Das ganze nennt sich Eclipse Angriff, weil man das eigentliche Netz, wie bei einer Sonnenfinsternis, nicht mehr sehen kann.
offensichtlich war die Software dagegen nicht gewappnet. Weil man das Netz als Korrektur nicht sieht, würden dann auch die „intelligenten“ :DDD Smart-Verträge ausgelöst werden, weil in der „falschen“ Blockchain, die passenden Bedingungen dafür „herrschen“.

Blockchaintechnik ist echt cool… wenn man Verbrecher ist 😀

Wie muß man sich das vorstellen ?

Ein Angreifer erstellt auf einem Server ein ganzes Rudel von Nodes.  Mit den Informationen vergiften er das Node-Cache des Opfer-Clienten. Wenn der absichtlich oder aufgrund eines ausgelösten DOS rebootet, hat er nur noch Nodeadressen die vom Angreifer kontrolliert werden.  Er ist damit vom Netz abgeschnitten und merkt es nicht mal.

Das gleiche gibts dann nochmal in einer „Ein-Server“ Version, aber technisch läuft es auf das gleiche hinaus!

Problem behoben

In der neusten Version 1.8 von der geth Software ist das Problem soweit behoben worden. Aber neu ist das Problem nicht, da es bereits seit 2015 bekannt war, als Forscher es einfach mal ausprobiert haben. Soooo sicher alles !!

Quelle: https://arstechnica.com/information-technology/2018/03/ethereum-fixes-serious-eclipse-flaw-that-could-be-exploited-by-any-kid/

Sächsische Polizei benutzte gebrochene Verschlüsselung

Diese Geschichte spielt im September 2016 und handelt davon ..

… das 365 Full-DisclosureTimer abgelaufen sind und ..

… Wie aus einer Maus ein Elefant wird

Im Zuge einer Ermittlung zu SSL Problemen eines Kunden, bin ich über ein SSL Problem der Polizei Sachsen gestolpert. Aufmerksame Leser meines Blogs ist das Thema SSL/TLS bei Mailservern nichts neues. Es reiht sich ein in Probleme wie die des CERT-BUND vom BSI , die sich im Vergleich dazu aber schnell schliessen liessen. Der Versuch, die Sicherheitslücke der zuständigen Abteilung  zu melden, artete regelrecht in einen Instanzenlauf aller „Die Zwölf Aufgaben des Asterix“ aus. Am Ende waren 6 Behörden daran beteiligt.

Was ist eigentlich passiert ?

Wer sein Mailserverlogfiles schonmal genauer angesehen hat, wird darin Angaben wie diese finden : „X=SSLv3:AES256-SHA:256″ . Diese stammen zwar jetzt von Exim, sind so aber auch in anderen Produkten zu finden. Bei dem X= handelt es sich um das Verschlüsselungsprotokoll ( SSLv3 ) und dem genutzten Verschlüsselungsalgorithmus/Cipher ( AES-256 mit Hashalgo SHA256 ) . Am Cipher gibt es nicht viel auszusetzen, klar, es gibt bessere z.B. AES256-GCM-SHA384:256, aber das ist nicht des Pudels Kern, sondern die Version SSLv3.

SSLv3 gilt seit 2 Jahren im Rahmen der POODLE Attacke als geknackt, zudem wurde es im Bereich Email vor über 15 Jahren schon von TLS abgelöst. Seit dem es als geknackt gilt, sollte man es auch nicht mehr einsetzen. Daher haben Internetprovider weltweit SSLv3 aus Ihrem Webservern und Emailservern entfernt. Jetzt wäre es falsch zusagen „Nur die Polizei Sachsen“ nicht, denn das stimmt nicht und wäre eh nur die halbe Wahrheit, denn es gehören immer zwei Server zu einer Übertragung.

Normalerweise läuft das so ab, daß sich sich der sendende und der empfangene Mailserver beim Verbindungsaufbau auf das Protokoll, den Cipher und den SessionKey einigen. Dabei wird erst TLS1.2 , dann TLS1.1 und dann TLS1/SSLv3 ausgewählt. Der Server der Polizei in Sachsen hatte nun SSLv3, also den schlechtesten Algorithmus gewählt, obwohl bessere zur Verfügung standen. Warum er das tat ist (war) noch Ziel einer Untersuchung. Die Kripo in Leipzig hat es auf sich genommen, das an die zuständigen Stellen weiterzuleiten und dafür zu sorgen, daß das zugrunde liegende Problem behoben wird.

Das war die Maus… und jetzt der Elefant

Für die Polizei betreut ein Dienstleister als sogenannter Staatsbetrieb die Netzwerke des Bundeslandes und seiner Behörden, das ist i.d.R. eine privat organisierte Tochter des jeweiligen Bundeslandes. In Sachsen ist das die „Staatsbetrieb Saechsische Informatik Dienste“ in Dresden. Wenn man jetzt glaubt, daß man dies ja nur dieser, für die Netze zuständigen Organisation mitteilen müßte, hat das noch nie probiert 😀

Dort habe ich natürlich zuerst angerufen um rauszubekommen, wer meine Kontaktperson sein wird. Pustekuchen. Die Leute da haben sich das zwar angehört, wollten aber aus externen Input nichts tun. Ich sollte das doch an den Polizeibeamten schicken der die fragliche Email geschickt hatte übermitteln, er würde das schon weiterleiten. Das habe ich gemacht.

und ….. ???

Nix. Gar nichts. Keine Empfangsbestätigung, kein Rückruf. Wie sich heute rausgestellt hat, war die Kripo Leipzig am letzten Freitag, Tag des Maileingangs, total überlastet. Der zuständige Mitarbeiter hat die Mail einfach weggeklickt, weil er den Inhalt auch nicht ganz erfaßt hatte. Zum Glück für die Polizei hat der besorgte ITler keine Ruhe gegeben und sich heute erneut durch die Instanzen gequält bis der zuständige Mitarbeiter sich dann selbstständig bei mir gemeldet hat.

Die nicht an behördenarme Suche soll hier skizzenhaft dargestellt werden:

Polizeidirektion Braunschweig
LKA Niedersachsen
LKA Sachsen
Polizeidirektion Leipzig
Staatskanzlei Sachsen
Bundesamt für Sicherheit in der Informationtechnik

als Optionen wären noch drin gewesen :

Landesdatenschutzbehörde Sachsen
Innenministerium Sachsen
Bundesministerium des Inneren
Verfassungsschutz Sachsen
Staatsschutz

Wenn es nach dem BSI gegangen wäre, wärs gleich beim Bundesministerium des Inneren gelandet, also ganz oben 🙂

Jetzt fragt Ihr Euch vermutlich wie der Verfassungsschutz da ins Spiel kommt. Das ist ganz einfach, das Mailserversystem des Landes mailt ja nicht nur Bürger an, sondern auch andere Behörden. Wenn jetzt also ein Konfigurationsfehler vorliegt, der dafür sorgt, daß der schwächste Algorithmus ausgewählt wird, dann sind auch Behörden- und damit Staatsgeheimnisse betroffen. Und da wir nicht so enden wollen wie die Amis, wo deren Politiker private Mailserver benutzen, sollten unsere Behördennetzte sicher sein. Davon profitieren wir alle, auch ganz direkt, denn Anwälte haben auch viel Emailkontakt mit der Polizei, Staatsanwaltschaften usw. .  Es will sicherlich niemand seine Aussage/Anzeige/ V-Manninfo von irgendwelchen in- und ausländischen Gruppen dekodiert bekommen, oder ?

Hier ein paar Sätze, die sinngemäß in den Gesprächen enthalten waren:

Auf die Frage: „Können Sie nicht einfach auf dem Dienstweg die Information weiterleiten?“

„Da ist eine andere Polizeibehörde, da haben wir keinen Dienstweg.“ ( PD Braunschweig )
„Das ist ein anderes Bundesland, da sind wir nicht weisungsbefugt.“  ( LKA Niedersachsen )
„Ich habe keine Ahnung wovon Sie da reden.“ ( Staatskanzlei Sachsen )

Die Dame in der Staatskanzlei hatte aber die passende Idee und dazugehörige Nummer von der PD Leipzig, so daß ich dort anrufen konnte, was dann über weitere Umwege zur Lösung geführt hat.

Die Behörden in Sachsen sind aus der Sicht der Polizei übrigens IT mäßig von unten nach oben frageberechtig, es kann also keiner von außen oben nachfragen, wie man dem Artikel ja auch entnehmen kann, sondern man muß jemandem am Ende der Kette aka. Mitarbeiter der PD Leipzig, z.B. ein Kripobeamter, die Sache aufnehmen lassen. Der darf dann seinen ITler fragen, was er sich da grade angehört hat und DER darf dann nach oben durchreichen, was zutun ist. Args!

Das skurillste Gespräch fand aber mit dem Netzbetreuer statt, dem Staatsbetrieb Saechsische Informatik Dienste :

„Wie sind Sie an diese Nummer gekommen ?“
„Steht im Whois des IP Bereichs drin.“
„??? Und warum rufen Sie hier an?“  ( Die Formulierung könnte leicht abgewichen sein)
„Weil ich …. entdeckt habe.“ ( die Sache mit dem SSLv3 )
„Was erwarten Sie jetzt von mir ?
„Das Sie das aufnehmen und intern weitergeben, damit es abgestellt wird.“
„Nö.“

Fazit

Dieser „Wir sind aber eine andere Behörde Kram“ ist doch dem Informanten egal und der Schutz von Staatsgeheimnissen sollte doch bitte schön allen Behörden am Herzen liegen. Vor allem wundert es mich ja, das überhaupt etwas Polizeiarbeit bundeslandübergreifend stattfindet, wenn die keinen Dienstweg dafür haben, wie machen die das dann ?!?!?!

Wie sorgt man nun auf seinem eigenen Mailserver dafür, daß SSLv3 nicht mehr geht ?

Also zunächst mal wärs ratsam ein aktuelles Linux zu haben, weil darauf aktuelle OPENSSL und GNUSSL Versionen wären. Je nach dem welche Kryptobibliothek man verwendet, gibt es unterschiedliche Wege.

Für Exim hält man sich am besten an dies hier: https://lists.exim.org/lurker/message/20141017.093614.e5c38176.de.html

Um eine Neukompilierung kommt man wohl nicht drumherum. Für den Anfang reicht es natürlich schon, wenn man SSv3 ans Ende und TLSV1.2 an den Anfang der Protokollverhandlungen stellt. Damit fällt SSLv3 dann praktisch auch weg.