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.

Munin: Could not draw graph

Kommt Euch bekannt vor ? „Could not draw graph „/var/lib/munin/cgi-tmp/munin-cgi-graph/…png?&lower_limit=&upper_limit=&size_x=800&size_y=400“

Wenn Ihr Upper & Lower – Limit auch nicht gesetzt habt, dann prüft doch mal , ob in der /var/www/cgi-bin/munin-cgi-graph das hier drinsteht: so um Zeile 462

my $upper_limit = CGI::param("upper_limit");
if ( $upper_limit eq "" ) {
   $upper_limit = "100000000";
}
push @params, "--upper_limit", $upper_limit if defined $upper_limit;

my $lower_limit = CGI::param("lower_limit");
if ( $lower_limit eq "" ) {
     $lower_limit = "0";
}
push @params, "--lower_limit", $lower_limit if defined $lower_limit;Falls nicht

Falls nicht, dann fixt das doch mal eben selber 😉  Seitdem geht unser Munin wieder.