Category Archives: Internet

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

Posted on by

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

Posted on by

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!

 

 

TLS-Gate – Online-Banking-Check

Posted on by

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.de––Digicert
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.de––Digicert
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!