Klimawandel – Äthiopier pflanzen in 24h 353 Millionen Bäume!

So Ihr kleinen Schulschwänzer, jetzt könnt Ihr Euch mal ansehen, wie man das wirklich macht mit der Klimaverbesserung! Äthiopien, ein Dritte-Welt-Land!, macht es Euch vor!

Äthiopier pflanzen in 24h 353 Millionen Bäume!

Ja, so geht das! 23 Millionen Menschen haben mitgemacht. Anstatt zu Reden, zu Schreien, zu Fordern und nicht zu verstehen, wie das geht, haben Euch die Afrikaner einfach mal so aus der Hüfte Links liegen lassen und stehen jetzt im Guinessbuch der Rekorde für die meisten Anpflanzungen an einem Tag!

Infos gibt es hier:

https://pmo.gov.et/greenlegacy/

hier: (Achtung Twitter Link )

und hier: (Achtung Twitter Link )

https://mobile.twitter.com/PMEthiopia/status/1155757837395660800/photo/1

und wer es auf Deutsch haben will:

https://rp-online.de/panorama/ausland/aethiopien-will-gruener-werden-353-millionen-baeume-in-zwoelf-stunden-gepflanzt_aid-44661849

Anmerkung: Nicht alleine der Klimawandel war der Anlass, man wollte auch etwas gegen Bodenerosion, Austrocknung und Versteppung tun. @Ähtiopien: Geile Aktion! Congratulation! 😀

Regionaltreffen der deutschen LUGs in Braunschweig

Am Samstag den 3.8.2019 finden in Braunschweig ab 12 Uhr das Treffen der Linux-User-Groups aus dem Norddeutschen Umland statt.

Afaik wird gegrillt, genetzwerkelt und zufällig auch über Linux gesprochen 🙂

Wer kommen will, ist herzlich ins ..

Nachbarschaftszentrum
Haus der Talente

Elbestr. 45
38120 Braunschweig

eingeladen. Wer sein „Linux“ mitbringen will, kann das gern tun: Internet, Strom, Beamer vorhanden.

FireFox: Netflix-Fehler M7399-1260 ist wieder da

Seit 2 Tagen ist Netflix-Fehler M7399-1260 wieder im Firefox zu sehen, wenn man versucht einen Film abzuspielen. Verursacht wird dies durch das „Netflix 1080p“ Add-On von Vladikoff.

Firefox, Linux und die 1080p Wiedergabe von Netflix

Es ist ein ewiger K(r)ampf zwischen den Leuten, die NetFlix auf Linux mit 1080p sehen wollen und NetFlix, das irgendwie so gar kein Interesse hat, das zuzulassen, obwohl die Leute dafür bezahlen. Deswegen haben zwei findige Menschen das Problem analysiert und unabhängig voneinander zwei Add-Ons für Firefox entwickelt, die das lösen: NetFlix 1080p ist so ein Add-On.

Seit 2 Tagen steuert NetFlix dagegen und verweigert die Wiedergabe, wenn das Add-On aktiv ist. Mozilla hatte das Add-On auch bereits aus dem Add-On-Repository verbannt, weil es Teile des NetFlix Sourcecodes modifiziert und mitgeliefert hat. Das führt zu der nicht so schönen Situation, daß Benutzer das Add-On nicht ohne weiteres mehr hinzufügen können. Updates gestalten sich auch eher aufwändig.

Workaround

Für Benutzer die das Add-On bereits installiert haben, gibt es einen einfachen Workaround:

Add-On abschalten, Film anstarten, anhalten und das Add-On wieder aktivieren.

Wenn man jetzt die Serie oder den Film wieder frisch! anstartet, ist er 1080p und es kommt keine Fehlermeldung M7399-1260 mehr. Scheinbar prüft NetFlix das nur einmal in der Session und danach kann das Add-On wieder übernehmen.

Kniffliger wird die Sache, wenn man das Add-On noch nicht hat. Da gibt es jetzt 1,5 Wege:

1)

  1. via about:config
  2.  xpinstall.signatures.required auf false setzen
  3. Add-On-XPI-File im Add-On-Manager von Hand installieren

Problem dabei, Ihr müßtet XPI Files aus dubiosen Quellen vertrauen. z.B. dem hier:

https://github.com/vladikoff/netflix-1080p-firefox/files/3438656/Netflix_1080p_v1.9_for_Fx.zip

Da es direkt von Valdikoff kommt, kann man dem Link wohl vertrauen. Bei anderen wäre ich vorsichtiger. Ich habe es daher ausprobiert und es geht. Einfach das ausgepackte XPI File nach .mozilla/firefox/<DEIN PROFIL>/extensions/  kopieren, Firefox neu starten. Fertig.

oder 2)

Das GitHub-Repo von Valdikoff ( Link oben ) auschecken und die Dateien als Extension selbst in den Extension-Ordner vom FireFox verfrachten. Leider gibt es dazu keine einfache Anleitung. Der Inhalt vom Git müßte in ein XPI File umgewandelt werden. Wenn man eh so weit ist, kann man es auch wie in 1) installieren.

Es hätte nur den Vorteil, daß man Updates verscripten könnte und das dann automatisch gemacht werden kann.

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 😉

 

 

ProFTPd – mod_copy Exploit … schon wieder

Keine gute Woche für altgediehnte  Linuxservices wie Exim und ProFTPd 🙁 ProFTPd hat einen Bug im Rechtemanagement von mod_copy, den man benutzen kann um als (anonymer) Benutzer sämtliche Dateien des Servers überschreiben kann: CVE-2019-12815

Schon wieder!

Es gibt zwar seit dem 17.7 einen Patch dafür, aber das ist nicht unbedingt dem profimäßigen Verhalten vom ProFTPd Team zu verdanken, sondern dem Debian-Security-Team, daß dem ProFTPd Team wohl mal in den Arsch getreten hat, wie diese Zeitangabe zeigt:

Timeline:

  • 28.09.2018 Reported to ProFTPd security@, ProFTPd asking for clarifications
    12.06.2019 Reported to Debian Security Team, replies by Moritz & Salvatore
    28.06.2019 Deadline for public disclosure on 28.07.2019 announced
    17.07.2019 Fix published by ProFTPd

2015 gab es so einen Fehler schon einmal in dem gleichen Modul „mod_copy“. Dies dürfte dazu geführt haben, daß es in der Default-Konfig von Fedora gleich mal auskommentiert ist. Normalerweise braucht man das auch nicht.

Das die Security-Typen bei ProFTPd für mich ein Haufen ignoranter Besserwisser sind, kann ich schon damit belegen, daß ich für den 29C3 einen Vortrag zum Thema „Chroot umgehen mit Links“ eingereicht hatte. Das eigentliche Problem hat das Security Team übrigens mit den Worten „Uns doch egal, haben wir in der Doku drauf hingewiesen“ abgewimmelt, nur im es dann Jahre später doch zu beheben.

Es muß offensichtlich erst ein namhafter Mitmensch kommen, damit dem geglaubt wird. Dabei hatte ich denen sogar einen Patch geschrieben, der das erfolgreich verhindert hat. Am Ende haben Sie es dann tatsächlich wie von mir vorgeschlagen mit einer entsprechenden Option „schaltbar“ gemacht. Ihr dürft mir glauben, gut zu sprechen bin ich auf die nicht und alleine auch nicht, wie man sieht!

 

 

Neue Exim Sicherheitslücke – Wieder Root Access

Erst vor kurzem haben sich die Wogen zum letzten Exim Exploit geglättet, da kommt die nächste Hiobsbotschaft vom Exim-Team: CVE-2019-13917 – Root Access für lokale und entfernte Benutzer.

Laut Ankündigung auf der Exim-Mailingliste sind wieder sämtliche halbwegs in Benutzung befindlichen Exim-Versionen betroffen 4.85 -> 4.92.1. In bestimmten, nicht Defaultkonfigurationen soll eine Root-Access-Lücke für lokale und entfernte Angreifer klaffen.

Mehr Details gibt es noch nicht, da erst am 25.7. offizielles Release Date ist. Wenn Ihr mehr wissen wollt, müßt Ihr einen Distro-Maintainer bestechen, oder 3 Tage warten. Sobald es was neues gibt, melde ich mich dazu.

zuviel Wind um Backdoor in OpenSSH

Wie Deutschlands Lieblings-IT-Verschwörer Fefe in seinem Blog berichtet, hat das FBI in einer Informationsfreiheitsanfrage zu OpenBSD mit einem Dokument geantwortet, daß auf eine Backdoor in OpenSSH hindeutet, allerdings schon im Jahr 2002.

Wo da jetzt die Neuigkeit war, wird allerdings nicht gesagt, was nicht verwundert, denn das war gar keine:

https://www.symantec.com/security-center/writeup/2002-111413-3305-99

Der Fall ging ordnungsgemäß durch die Securityportale 🙂 Da war wohl der FTP Server von OpenBSD aufgehebelt worden und jemand hat den Sourcecode verunreinigt. Wurde gefunden, wurde behoben, wurde vergessen 😀

TLS-Gate – Online-Banking-Check

Schlechte Nachrichten für Eure Online-Banking Sicherheit:

18 von 20 getesten Online-Banking-Webseiten erlauben gebrochene Krypto!

In einem kleinen Test mit zufällig ausgewählten Online-Banking Webseiten, haben nur zwei Vertreter schon mal etwas von Security gehört. Die in der Liste grün hervorgehobenen Banken hatten nur TLS 1.2+ im Einsatz, wohin gegen die Anderen TLS 1.0 und TLS 1.1 neben TLS 1.2 erlaubt haben.

Damit sind Szenarien möglich, bei der es Angreifer schaffen, das SSL-Protokoll auf TLS 1.1 zu drücken, oder das gleich uralte Browser und Betriebssysteme zum Einsatz kommen, die von selbst mit gebrochener Krypto Verbindung zur Bank aufnehmen.

So oder so, ein Fest für Abhörer und Kriminelle.

Alle Banken hatten keine Probleme mit TLS 1.2, so daß ein aktueller Browser sich mit einer sicheren Verbindung zur Bank verbunden hat. Eure Sicherheit ist also nur dann gefährdet, wenn Euch jemand angreift und das ist genau das, was man mit guter Security verhindert. Wenn der Bankwebserver kein TLS 1.0 anbietet, würde so ein Angriffsszenario, bei dem die Verbindung derart gestört wird, daß TLS 1.2 nicht zu stande kommt, gar nicht erst funktionieren können.

Dummerweise gabs es in der Vergangenheit genug Beispiele, wie man solche Angriffe auf SSL-Verbindungen durchführt. Es ist also nicht ausgeschlossen, daß es jemand auch bei Euch schafft.

Domainname[:443]TLS 1.0TLS 1.1CA
www.commerzbank.de++Digicert
www.nordlb.de++Digicert
www.ksk-stade.de++Digicert
meine.postbank.de++Digicert
meine.deutsche-bank.de++Digicert
www.berliner-sparkasse.de++Digicert
www.bv-activebanking.deDigicert
meine.norisbank.de++Digicert
www.dkb.de++Digicert
www.sparda-b.de++QuoVadis
www.vrbankmecklenburg.de++QuoVadis
www.volksbank-demmin.de++QuoVadis
calenberger.de (Calenberger Kreditverein)++Lets Encrypt!
www.ksk-walsrode.de++Digicert
www.diebank.de++QuoVadis
www.sparkasse-celle.de++Digicert
banking.seeligerbank.deDigicert
www.sparkasse-nordhorn.de++Digicert
hbciweb.olb.de++D-Trust GmbH
www.apobank.de++QuoVadis

Wie kommt das zu Stand?

Wie man das erwarten würde, gibt es Gruppen von „Banken“ die eigentlich nur Filialen eines Konzerns sind. Mag sein, daß der eine oder andere örtliche Bankvorstand das anders sieht, aber spästens wenn jemand mal Geld nachschiessen muß, sieht man, wer mit wem verbandelt ist.

Die Sparkassen haben daraus gleich eine Tugend gemacht und einen eigenen Sparkassen Webframework gebaut. Im Prinzip ist die Online-Bankingseite für alle Sparkassen gleich, lediglich das Logo und Name & Anschrift der Bank in Texten sind angepaßt. Da Banken und Sparkassen nicht in jedem x-beliebigen Rechenzentrum hosten dürfen, gibt es nur wenige Anbieter auf die sich die Dienste verteilen.

Folge, so wie jetzt, fällt eine Webseite negativ auf, sind alle Seiten des Konglomerats betroffen.

Es ist an Euch das zu ändern in dem Ihr selbst zu Eurer Bank geht und das moniert.

Wie beweist Ihr das?

Man verbindet sich mit der Bankseite und sagt openssl nur TLS 1.0 anzubieten :

openssl s_client -connect www.apobank.de:443 -tls1

New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 9F46E16A883DB49FA5A516BCDB23B67F24ED12E5EA6F9F83C504A6CF4CA96A24
Session-ID-ctx:
Master-Key: 4166D9B1C922F2410E6C0BF98BBE1D4B9BA03F238A6112F7FFA6B624F0BDFD8F7F759D97BDCB108CC3E4E635EBA17E24

Kommt eine Session und Key zustande, hatte man mit seiner Bank leider Pech 🙂

So sieht das aus, wenn man mit der Bank Glück hatte :

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1563537522
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no

Keine Session. Kein Key. Kein Problem!

Update: Fedora: Probleme mit hwdata und Asus Mainboards

Wie bereits vor zwei Tagen mitgeteilt, gibt es bei Fedora ein Problem mit dem Paket hwdata. Darin sind die PCI Ids der Geräte und Hersteller enthalten. Die Quelle der Daten wird bei Github gepflegt und damit betrifft es nicht nur Fedora, sondern alle Distributionen, die Ihre Daten von dort beziehen.

Die Datei oui.txt (Organisational Unit Ids) verursacht dies, offensichtlich sind dort Kennungen falsch eingetragen  oder verloren gegangen, so das Wechselmedien nicht sauber erkannt werden.

Kuriose an der Sache: Der eingesteckte USB Stick war für Root gemountet und nicht für den angemeldeten User.

Wie eine falsche OUI das auslösen kann, wird derzeit geprüft. Ich meine, da liegt ein ziemlich dicker Bug kurz vor seiner Entdeckung.

+49 69 4310097

Falls jemand Probleme hat raus zubekommen, wer Ihn da ständig auf seinem Handy beglückt, es ist ein Tochterunternehmen der Commerzbank namens…

Commerz Systems GmbH
Helfmann-Park 5, 65760 Eschborn
Telefon: +49 69 43100

Stand: 15.7.2019

Da ist die Absichtserklärung schon im Unternehmesnamen verankert. In den „Datenschutzhinweise für Kunden und andere Betroffene“ heißt es auf Seite 3 ..

Widerspruchsrecht gegen eine Verarbeitung von Daten für Zwecke der Direktwerbung

Widersprechen Sie der Verarbeitung für Zwecke der Direktwerbung, so werden wir Ihre personenbezogenen Daten nicht mehr für diese Zwecke verarbeiten

Der Widerspruch kann formfrei mit dem Betreff „Widerspruch“ unter Angabe Ihres Namens, Ihrer Adresse und Ihres Geburtsdatums erfolgen und sollte gerichtet werden an:
…Adresse siehe oben…

Böse Zungen könnten jetzt die Behauptung ableiten, daß der Widerspruch zu einer ohnehin nach DS GVO nicht zulässigen Verarbeitung(Opt-Out zu einer nur per Opt-In zulässigen Verarbeitung), nur dafür da ist, um die Daten zu verifizieren oder gar erst zu erlangen.

Wer wissen will wie die Rechtslage ist:

https://www.call-center.de/callcenter-service/recht/telemarketing/privat.html

Essenz: „Anruf zur Geschäftsanbahnung ist nur mit ausdrücklicher ( Opt-In ) Einwilligung legal.“ Diese Einwilligung liegt nicht vor.

Wie könnte man darauf kommen?

Im aktuellen Fall gibt es nur die Telefonnummer ohne Namen, einen Anruf und keine Nachricht auf der Mailbox der Nummer.  Mit dem Widerspruch zu Speicherung, Verarbeitung und dem Verbot des vermutlichen Telefonspams der Nummer, würde der vermeindliche Spammer auch noch valide Daten erhalten: Name, Adresse und (komplett überflüssig) Geburtsdatum der Person hinter der bespammten Nummer. Also eine klare WIN Situation für den Spammer.

Da bereits Zweifel an der Seriosität bestehen, da Cold-Calls bei Verbrauchern zu Marketingzwecken gar nicht mehr erlaubt sind, darf auch bezweifelt werden, daß die zum Widerspruch gehörenden Angaben ordnungsgemäß vernichtet werden, wenn der Widerspruch bearbeitet wurde. Die Begründung wird sein, daß man ja ohne die Datenspeicherung gar nicht wüßte, wen man nicht anrufen soll.

Wenn allerdings nur korrekt erhaltene Daten von Kunden verarbeiten würden, die eine Zustimmung dazu gegeben haben, ergäbe sich das Problem gar nicht erst.