Lets Encrypt: Zertifikatsprobleme auf iOS Geräten

Seit Dezember 2015 stellt Lets Encrypt kostenlose Zertifikate zur Verfügung. Damit kann man Webseiten und Mailserver schützen, wenn da nicht die liebe Realität in Form von iOS wäre.

Bei unserem hausinternen Versuch, die Mailserver von einem kommerziellen Comodozertifikat auf Lets Encrypt umzustellen, was für Webseiten überhaupt kein Problem war, stellte sich raus, das sofort alle iOS Endgeräte, egal ob iPhone 5,6,7 oder iOS 9,10 keine Emails mehr empfangen konnten. Entäuschenderweise war auch Thunderbird betroffen 🙁

Daraufhin haben wir auf ein Comodozertifikat umgestellt und die Lage beruhigte sich, bis einige iOS Geräte anfinden, nur noch Emails zu senden, aber keine mehr zu empfangen. Wohlgemerkt, mit dem gleichen SSL-Zertifikat 😉

Nach derzeitigen Erkenntnissen seitens Comodo und unseren Technikern, liegt das Problem beim iOS Gerät selbst. Mal sehen was Apple dazu meint.

Auflösung: Mail.APP ist buggy, denn jedes andere installierte Emailprogramm auf einem betroffenen IPhone hat das Zertifikat einwandfrei akzeptiert. Aber der Witz kommt jetzt, dem Kunden hat das neue Mailprogramm „My Mail“  viel besser gefallen als die original App 😀

 

Exploits via JPG Bilder im Umlauf

Manchmal machen es einem den Verbrecher besonders einfach, nicht auf Ihre Masche hereinzufallen. Wer als Deutscher sowas in der Email hat:

Chinesische Emailklickt gar nicht erst auf die Grafik, die im Anhang drin ist drauf, sondern löscht die Mail gleich.

Trotzdem sollten alle Leser auf der Hut sein, denn im JPEG2000 Decoder diverser Anwendungen und Betriebssysteme steckt ein schwerer Fehler, der es dem Angreifer erlaubt, Code auf dem PC des Opfers auszuführen, alleine durch das Ansehen von veränderten Bildern.

Wer im obigen Bild genau hingesehen hat, der hat unten das Attachement gesehen: „…. .jpg“

Ausschnittvergrößerung

Inhaltlich hatte die Spam nichts zu bieten, spaßeshalber habe ich den Text mal übersetzen lassen:

您好:

敝司為保健食品品牌商,敝司優秀的研發團隊研發出一支百億活性益生菌粉劑,且與擁有HACCP/ISO22000雙項國際食品安全管理系統以及國內首批通過TQF之生技大廠配合,不論是產品原料,配方,生產品質均優良

Hallo:

Geräumige Sekretär für Gesundheit Lebensmittel-Marken, geräumige Sekretär hervorragende F & E-Team entwickelte eine zehn Milliarden aktiven Probiotika, und mit dem Besitz von HACCP / ISO22000 Dual internationalen und nationalen Lebensmittelsicherheit-Management-System durch die erste Charge von komplexen Biotech-Riese TQF , ob Rohstoffe, Formulierungen, die Produktionsqualität sind ausgezeichnet

Kommt nur Gebrabbel raus. Kein Wunder daß übersetzte Spams so leicht zu erkennen sind 😉

Also, wie immer, nicht Lesen, sondern ab in die Tonne damit.

CVE-2016-7543: gravierende Schwachstelle in Bash < 4.4

Durch eine fehlerhafte Auswertung von Umgebungsvariablen, kann ein lokaler Angreifer beliebigen Code als Root ausführen.

Wichtig sind zwei Parameter:

A) Er muß die Umgebungsvariablen beeinflussen aka. setzen können.

B) Er muß ein Programm starten können, daß Root gehört und das „+s“ (SetUID) Flag hat.

Mehr Infos Link: http://seclists.org/oss-sec/2016/q3/617

Wer ist betroffen ?

Betroffen ist u.a. die gesamte Fedora Palette:

Red Hat Fedora 23
Red Hat Fedora 24
Red Hat Fedora 25

Es dürften aber alle, die Bash < 4.4 einsetzen von dem Problem betroffen sein und betrifft wohl jeden Desktopnutzer.

Warum melde ich das heute, ist doch nur eine Sicherheitslücke unter vielen ?

Ohne Bashing betreiben zu wollen, aber im OSBN tauchte heute folgender Beitrag auf :  Defektes Piwik nach Update auf 2.16.3

Kurzfassung: Weil Piwik (Webanalysesoftware wie Google Analytics) plötzlich nach einem Update  500er Fehler geworfen hat, entfernte der Serverbetreiber einfach Kurzerhand die paar Restsicherheitsmaßnahmen des Apachewebservers und erlaubte es dem Piwik unnötige und sehr gefährliche Apache-Directiven in der .htaccess  auszuführen. (Wie ich grade gesehen habe, ist mein Protest auf fruchtbaren Boden gefallen und er hat es korregiert 😀 )

Hintergrund des Protestes ist, daß mit der Anweisung „AllowOverride All“ in einer Htaccess auch AddHandler und Action Anweisungen erlaubt sind.  Mit denen kann u.a. das machen :

AddHandler php-script .php .pl .rb .py .exe .cgi .sh 
Action php-script /cgi-sys/cgiwrap

Mit „/cgi-sys/cgiwrap“, was ein CGIWrapper wie FastCGI oder ein Eigenbau wie bei uns sein kann, sorgt der Webserverbetreiber normalerweise dafür, daß Prozesse als User und in einer Chroot ausgeführt werden, statt als Apachebenutzer und mit Zugriff auf “ / „. Kann ich die Optionen als Angreifer frei setzen, kann ich eigene Kommandos statt des Cgiwrappers ausführen und damit auch außerhalb der Chrootumgebung. ( Klar das Ausführen von Programmen geht beim Webangriff auch anders, gehen wir mal davon aus, daß das der einzige Weg wäre).

Wenn ich eigene Kommandos ausführen kann, kann ich obige Schwachstelle ausnutzen und Root werden. Da die obige Schwachstelle der Bash darauf beruht, daß man eine SETUID Programm ausführen muß und in einer CHROOT keine SetUID Programme von Root sind, weil es keinen Root User gibt(der ist da prinzipbedingt unnötig), kann man trotz verwundbarer Version von Bash, den Angriff nicht durchführen.  Kann ich aber den Wrapper umgehen und im Realsystem arbeiten, finde ich auch Root-SetUID Programme und der Hack gelingt.

Und deswegen trägt man in seinen Vhost das hier ein : „AllowOverride AuthConfig Indexes Limit FileInfo“ und nichts anderes.

So tragen verschiedene Mechanismen dazu bei, daß ansonsten verwundbare Systeme doch nicht geknackt werden. Die Bash braucht man oft auch in der Chroot, außer man hat keine generelle Hostingumgebung, sondern läßt da genau eine Sache drin ablaufen, was auch legitim wäre.