Ein heuristischer Sicherheitsansatz mit Hilfe von Domino Statistiken

7. Dezember 2015 Posted by Manuel Nientit

IBM Domino

Der Begriff "Heuristische Analyse" wird im Zusammenhang mit Anti-Malware-Software ins Spiel gebracht und soll beschreiben, dass die Software nicht nur nach bestimmten Signaturen bzw. Hashes prüft, sondern auch das "Verhalten" einer Software bewertet, um herauszufinden, ob diese schädlich sein könnte. Der Grundgedanke lässt sich sinnvollerweise auch auf andere Sicherheitsfelder bzw. IT-Sicherheit allgemein ausweiten. Die Idee ist, Abweichungen von "normalem" Verhalten zu identifizieren bzw. diese Abweichungen in einem größeren Kontext miteinander in Verbindung zu setzen, um so Hacks oder den Befall durch Schadsoftware identifizieren zu können.

Ein Beispiel aus dem wahren Leben der jüngeren Vergangenheit soll erläutern, was ich meine:
Ein Kunde ruft an und beschreibt, dass einer seiner Nutzer seltsame Zustellungsfehler-Nachrichten bekäme, obwohl der die entsprechenden Adressen nicht adressiert habe. Ein kurzer Blick auf seinen Server zeigt, dass der Domino-Server, der im Internet steht, zu einem Spam-Relay umfunktioniert worden war. Klassischer Fehler, denkt man sich; aber nein, der Server ist so eingestellt, dass er nur authentifizierten Nutzern, das relaying erlaubt. Ein genauerer Blick offenbart, dass es einen Account gibt, mit dessen Autorisierung von wechselnden asiatischen IP-Adressen SMTP-Verbindungen zum Versenden von E-Mails aufgebaut wurden. Der fragliche Account ist offenbar gehackt. Die Ursache ist schnell bereinigt und die Folgen behoben.

Dieses Beispiel soll vor allen Dingen zeigen, dass auch "legales" Verhalten schädlich sein kann. Es wurden gültige Credentials genutzt, freigeschaltete Ports verwendet, keinerlei Protokollfehler missbraucht, keine Malware installiert... Firewalls und Anti-Virensoftware hatten niemals eine Chance. Der Fehler wurde mehr oder weniger zufällig bekannt.

Doch das muss keineswegs so sein. Eine genauere Beobachtung der Vorgänge auf dem Server hätte zeigen können, dass es eine ungewöhnlich hohe Anzahl von versendeten E-Mails gab, die aufmerksam hätte machen können. Natürlich kann kein Mensch die entsprechenden Kennzahlen immer im Auge behalten. Vielmehr gibt es Werkzeuge, die das für einen Administrator übernehmen können. Die Beobachtung kann durch den Domino Statistic Collector übernommen werden.
Man erstellt einen Event-Generator zum Beispiel für den Wert: mail.delivered, so dass ein Alarm ausgelöst wird, wenn ein bestimmter Threshold überschritten wird. Wie hoch der Threshold ausfällt, ist natürlich individuell, denn nicht nur muss man die normalen Werte in der jeweiligen Umgebung kennen, sondern auch seine akzeptablen/unverdächtigen Maximalwerte kennen, damit man eine Abweichung überhaupt identifizieren kann, ohne allzu viele falsche Alarme zu erzeugen.
Für die Überwachung dieser Art ist keinerlei Zusatzsoftware erforderlich, es reicht die sorgfältige Konfiguration der Domino Statistiken und Events. Hierbei helfen wir gerne.

Die Sicherheit der Aussagen der Überwachung könnte erhöht werden, indem man einzelne Werte miteinander in Beziehung setzt, da ein Account, der außergewöhnlich viele E-Mails sendet, in großen Rauschen verloren gehen kann, aber wenn man gleichzeitig die Zahl der Authentifizierungsvorgänge und eventuell auch die Zahl der verschiedenen Ziel-Maildomänen in Relation setzte, hätte man schon einen ziemlich klaren Hinweis auf einen Sicherheitsvorfall. Für solche Anforderungen hat IBM auch einiges im Köcher. Auch dabei beraten wir gerne.

Browser stellen Support für Java Plug-ins ein – Notes-Webanwendungen gefährdet

1. Dezember 2015 Posted by Manuel Nientit

Eine kürzlich veröffentlichte Technote von IBM, die unter der Nummer "LO86718" firmiert, macht darauf aufmerksam, dass Browser-Hersteller ihren Java-Support zurück fahren.
Google's Chrome hat bereits im September die Unterstützung für NPAPI-Plugins komplett eingestellt.
Mozilla hat gleiches im Firefox für Ende 2016 angekündigt.
Für Apple's Safari konnte ich kein Statement finden, aber es ist kein Geheimnis, dass sich Apple mit Plugins generell eher schwer tut - die Entscheidung, Flash nicht zu unterstützen, hat bekanntermaßen hohe Wellen geschlagen.
Microsoft's neuer Edge-Browser unterstützt die NPAPI-Alternative ActiveX nicht mehr.

Diese Ankündigung betrifft zwei Felder:
Klassische Notes-Webanwendungen benutzen NPAPI-Plugins für die Darstellung der Aktionleiste, der Outline und des Rich-Text-Editors, so dass diese mit dem Wegfall der Unterstützung nicht mehr funktionieren.
Anwendungen die von uns explizit webfähig entwickelt wurden, sind nicht betroffen. Aber jede Notes-Anwendung, die ohne weitere oder nur geringfügige Anpassungen auf einem Domino-Webserver geöffnet wird, benutzt diese Plugins zu Darstellung der besagten Elemente. Neben Anwendungen anderer Anbieter sind eventuell auch Anwendungen von IBM Standardschablonen betroffen.

Das Notes Browser Plug-in/ICAA beruht zu nicht unerheblichen Teilen auf der NPAPI, wodurch es in seiner aktuellen Version komplett hinfällig wird.

IBM hat das Problem zwar erkannt, aber noch keinen Plan verlautbaren lassen, wie und wann sie es zu lösen gedenken.

Der geneigte Leser mag jetzt für sich entscheiden, wie er die folgende Spekulation meinerseits bewertet:
Für ICAA bedeutet diese Information, dass es wohl von Grund auf neu entwickelt werden müsste. Da ICAA von IBM ohnehin nur als Lückenfüller bzw. Übergangslösung zwischen einer Fat-Client-Strategie und einer Browserstrategie gedacht war, fehlt mir die Phantasie für die Vorstellung, dass IBM nochmal von vorn beginnt. Auf der anderen Seite, ist das Thema schon lange genug bekannt. Wäre eine Entscheidung gefallen, hätte sie schon kommuniziert werden können. Wiederum verstreicht wertvolle Zeit während wohl immer noch darüber "nachgedacht" wird(?).
Im Verhältnis zu ICAA ist das Problem der Java Plug-ins für Notes-Web aus IBM Sicht ein kleines. Aber hier setzt IBM schon seit längerem auf XPages und andere Technologien. Das zusammen mit der Vermutung, dass die Plugins in neueren Entwicklungen vermutlich (hoffentlich?) nicht mehr eingesetzt werden, könnte dazu führen, dass IBM die Plug-ins einfach ersatzlos sterben lässt.

Unabhängig von Ihrer Bewertung empfehlen wir, Ihre Strategie bzw. Ihre Anwendungen diesbezüglich auf den Prüfstand zu stellen, um sich von der Entwicklung zumindest nicht überraschen zu lassen.
Gerne unterstützen wir Sie ergebnisoffen bei der Evaluation und/oder ggf. bei Neuentwicklungen.

Quellen:
Technote zum Thema - leider nur mit IBM-ID zu öffnen
Google Support zur Einstellung der NPAPI Unterstützung
Mozilla zur Einstellung der NPAPI Unterstützung
Microsoft zur Einstellung von ActiveX
Vorstellung des Notes Browser Plug-ins auf der Connect 2013

IBM Notes Traveler: Drei Fallen beim Update auf iOS 9

18. September 2015 Posted by Manuel Nientit

IBM Notes Traveler
Es gibt drei Gründe, das aktuelle iOS 9 Update vorsichtig anzugehen:

Erstens

Es gibt ein bekanntes Problem bei der Synchronisation wiederholender Termine mit iOS 9-Geräten. Das ist aber schon in der Version 9.0.1.7 von IBM Notes Traveler, die kürzlich erschienen ist, gelöst.

Zweitens

Die neue "Apple Transport Security" sieht vor, dass TLS-Verbindungen von Apps nur mit ECDHE (Elliptic Curve Diffie-Hellmann Encryption) aufgebaut werden sollen. Nachzulesen ist das in der Technote 1966059. ECDHE wird von Domino aktuell noch nicht unterstützt. Allerdings ist das wohl vorerst kein Problem, da die Nachrichten-App die ATS wohl noch nicht konsequent umsetzt. Das hat Daniel Nashed getestet und in seinem Blog-Eintrag dokumentiert. Allerdings ist es m. E. nur eine Frage der Zeit, dass sich das ändert. Aber ein Update, das die ECDHE-Unterstützung nachinstalliert steht mit dem FP5 bereits in der Pipeline und erscheint voraussichtlich noch diesen Monat.

Drittens und vermutlich wichtigstens

Selbst-signierte Zertifikate werden vom Gerät nicht mehr akzeptiert, so dass dieses die Synchronisation einstellt. Dementsprechend müssen alle, die noch auf selbst-signierte Zertifikate setzen, neue erstellen und diese durch eine "Trusted CA" signieren lassen.

Gerne stehen wir für Fragen oder Unterstützung zur Verfügung.

Domino von LogJam-Lücke in TLS nicht betroffen

22. Mai 2015 Posted by Manuel Nientit

IBM Domino
Tja...
Anfang der Woche schrieb ich bereits über eine bekannt gewordene Lücke in SSL/TLS nun folgt direkt die Nächste.

Diese nun LogJam genannte Lücke mit der CVE-ID "CVE-2015-4000" betrifft Server wie Clients gleichermaßen. Diese Lücke im DHE ermöglicht wohl einem "Man-In-The-Middle" eine Downgrade-Attack auf andere Verschlüsselungsstärken, so dass mitgeschnittener Netzwerkverkehr gelesen bzw. manipuliert werden kann.
Ich habe von IBM bisher keine offiziellen Statements gefunden, die eine Auskunft über die Betroffenheit der IBM-Produkte gibt. Wenn einer unserer Leser mehr weiß, ist er herzlich gebeten einen entsprechenden Kommentar zu hinterlassen .

Aber mehrere Dinge lassen sich sagen:
Domino kann vor 9.0.1 FP3 IF2 kein DHE. Ältere Domino-Versionen sind also deswegen schonmal nicht betroffen.

DHE muss in Domino 9.0.1 FP3 IF2 explizit eingestellt werden. In der Standardeinstellung ist Domino 9.0.1 FP3 IF2 also ebenfalls nicht betroffen.

Man kann seinen Server auf weakdhe.org auch testen lassen und erhält nebenbei auch Auskunft über die Verwundbarkeit seines Browsers . Darren Duke hat das einmal für einen seiner Domino-Server mit aktiviertem DHE getan und der Test bestätigt ihm keine Verwundbarkeit.
Wer sich nicht auf diese Webseite verlassen möchte oder Server testen möchte, die nicht im Web stehen, kann dies auch mit openssl tun.

Diese Aussagen ersetzen zwar m.E. kein offizielles Statement von IBM, lassen aber mit ausreichender Sicherheit vorläufig feststellen, dass
IBM Domino nicht von der LogJam-Lücke betroffen ist.

Sicherheitslücke in SSL RC4 Cipher betrifft auch Domino

18. Mai 2015 Posted by Manuel Nientit

IBM Domino
Die Welle der auf SSL bezogenen Sicherheitslücken reißt nicht ab. Diesmal betrifft es die Cipher RC4.
Mit dieser, "Bar Mitzvah" genannten, Sicherheitslücke kann ohne "Man-In-The-Middle" gesniffter Netzwerkverkehr zwischen einem beliebigen Client und Domino-HTTP entschlüsselt werden.

Diese Sicherheitslücke betrifft alle Domino-Server vor 9.0.1 FP3 IF2.

Wer in den letzten Monaten von uns einem Sicherheitsaudit unterzogen wurde, hat nichts mehr zu tun . Alle Anderen sollten die RC4 ciphers deaktivieren oder gleich auf die letzte Domino-Version aktualisieren, sofern möglich.

IBM veröffentlicht SSL/TLS Dokumentation für Domino

4. Mai 2015 Posted by Manuel Nientit

IBM Domino
Ich suche schon lange nach einer guten und detaillierten Dokumentation für die SSL/TLS Fähigkeiten des Domino HTTP Dienstes. Diese Suche hat im Zusammenhang mit den SSL-bezogenen Sicherheitsproblemen der letzten Monate noch etwas mehr Brisanz gewonnen.
IBM hat nun endlich am Anfang diesen Monats eine solche Dokumentation veröffentlicht. Und da ich davon ausgehe, dass ich nicht der Einzige bin, der danach gesucht hat, möchte ich das unseren Lesern nicht vorenthalten :
TLS Cipher Configuration

Natürlich gilt diese Dokumentation nur für die Domino Versionen ab 9.0.1 FP3 IF2, aber sie wird bestimmt/hoffentlich in der Zukunft aktualisiert.

Mehrere Dinge sind wichtig.
Zum Einen geschieht die Konfiguration nicht mehr über das Serverdokument, sondern ausschließlich über die notes.ini. Zum Anderen sind nicht alle wichtigen Features, wie zum Beispiel Forward Secrecy, im Installationsstandard aktiviert. Das bedeutet, dass zwar die Standardkonfiguration mit Auslieferungszustand solide ist, es sich jedoch dennoch lohnt, sich darüber Gedanken zu machen.

Damit kann man den Domino nun übrigens auch weitestgehend entsprechend den Empfehlungen des BSI konfigurieren. Dazu gehört aber auch, dass SSLv3 und TLS 1.0 deaktiviert werden.
Wer sein Zertifikat mit der Cert-Admin-DB angelegt hat, sollte es erneut anlegen, um den aktuelleren Hash SHA256 nutzen zu können.

IBM veröffentlicht SSL/TLS Dokumentation für Domino

4. Mai 2015 Posted by Manuel Nientit

IBM Domino
Ich suche schon lange nach einer guten und detaillierten Dokumentation für die SSL/TLS Fähigkeiten des Domino HTTP Dienstes. Diese Suche hat im Zusammenhang mit den SSL-bezogenen Sicherheitsproblemen der letzten Monate noch etwas mehr Brisanz gewonnen.
IBM hat nun endlich am Anfang diesen Monats eine solche Dokumentation veröffentlicht. Und da ich davon ausgehe, dass ich nicht der Einzige bin, der danach gesucht hat, möchte ich das unseren Lesern nicht vorenthalten :
TLS Cipher Configuration

Natürlich gilt diese Dokumentation nur für die Domino Versionen ab 9.0.1 FP3 IF2, aber sie wird bestimmt/hoffentlich in der Zukunft aktualisiert.

Mehrere Dinge sind wichtig.
Zum Einen geschieht die Konfiguration nicht mehr über das Serverdokument, sondern ausschließlich über die notes.ini. Zum Anderen sind nicht alle wichtigen Features, wie zum Beispiel Forward Secrecy, im Installationsstandard aktiviert. Das bedeutet, dass zwar die Standardkonfiguration mit Auslieferungszustand solide ist, es sich jedoch dennoch lohnt, sich darüber Gedanken zu machen.

Damit kann man den Domino nun übrigens auch weitestgehend entsprechend den Empfehlungen des BSI konfigurieren. Dazu gehört aber auch, dass SSLv3 und TLS 1.0 deaktiviert werden.
Wer sein Zertifikat mit der Cert-Admin-DB angelegt hat, sollte es erneut anlegen, um den aktuelleren Hash SHA256 nutzen zu können.

Quick Tipp: Schnelladressierung zuerst auf dem Server suchen lassen

20. März 2015 Posted by Manuel Nientit

Quick-TippIBM Notes
Kürzlich kam bei einem Kunden die Frage auf, warum denn die "privaten" E-Mail-Adressen eines Kontaktes in der Vorschlagsliste bei der Schnelladressierung höher angezeigt werden, als die beruflichen.
Das liegt natürlich zunächst einmal mit daran, dass Notes natürlich nicht von sich aus zwischen beruflich und privat unterscheiden könnte - wie sollte auch das gehen? Aber hängt auch damit zusammen, dass Vorschläge nach Häufigkeit der Korrespondenz gewichtet angezeigt werden.

In diesem Fall war es jedoch so, dass das Workspace-Verzeichnis, in dem die Datenbank für die Gewichtung (DIP) abgelegt ist, zurückgesetzt worden war. Somit waren private und die berufliche Adressen erst einmal theoretisch gleichwertig. Allerdings fließt hier außerdem die Standardsuchreihenfolge ein, die bei der Schnelladressierung immer erst lokale Adressbücher und dann erst Serveradressbücher berücksichtigt.

Aber genau das ist einer der Punkte, an denen man einhaken kann, indem man die Schnelladressierung die Adressen vom Server stärker gewichten lässt als die lokalen. Zu diesem Zweck muss, beginnend mit Notes 8.5.3, die Variable:
TypeAheadShowServerFirstDefault=1
in die notes.ini eingetragen werden.
Details dazu können auch hier nachgelesen werden: "New Type-ahead Feature in Notes v9"

Das Ergebnis sieht aus, wie in folgendem Screenshot:
Schnelladressierung_mit_ServerFirst.png
Die Treffer von Server-Adressbüchern inklusive Verzeichnisunterstützung werden oben gelistet und erst dann unter "Local Directory" die Treffer aus allen lokalen Adressbüchern.

Dieses Ergebnis mag auch nicht für alle Nutzer und alle Situationen nützlich sein. Das ist sehr stark abhängig von der Gesamtkonfiguration der Adressbücher und der persönlichen Nutzung. Daher gibt es hier keinen goldenen Weg.

Die Schnelladressierung in Notes ist ein sehr hilfreiches und wertvolles Feature. Aber auch das Feature das vermutlich alleine mit am meisten Supportfälle verursacht. Nicht zuletzt, weil es nahezu untrennbar mit dem nicht minder wertvollen Feature "Letzte Kontakte", das seinerseits für einige Fragen gut ist, verheiratet ist. An dieser Stelle sind Administratoren herausgefordert, ihre Nutzer zu kennen und sinnvolle Vorgaben zu machen und gleichzeitig den First-Level-Support zu schulen, bestimmte Fragen diesbezüglich beantworten bzw. die Konfiguration wie oben kurzfristig ändern zu können.

Sicherheitslücke im Android Standardbrowser

9. Oktober 2014 Posted by Manuel Nientit

Bereits Anfang September wurde offenbar eine nicht unbedingt kleine Sicherheitslücke im Android Standardbrowser AOSP entdeckt. Damals ist mir das leider entgangen. Ich wurde erst jetzt wieder darauf aufmerksam als golem erneut berichtete und feststellte, dass ca. 60% der deutschen Android-Nutzer davon betroffen sein dürften.
Betroffen sind nämlich Android Versionen < 4.4, die weltweit auf immer noch ca. 75% der Geräte kursieren.

Der Fehler betrifft die "Same-Origin-Policy", die verhindern soll, dass Webseiten über den Browser auf Inhalte anderer Webseiten zugreifen können. Durch die Lücke ist es präparierten Webseiten nun möglich, auch zum Beispiel auf die Cookies oder Inhalte anderer geöffneter Webseiten zuzugreifen. Nachrichteninhalte oder gar Anmeldedaten können so ausgespäht werden.
Es wurde bereits ein Patch veröffentlicht. Allerdings kommt hier der große Nachteil der hohen Fragmentierung der Android-Welt zum Tragen: die jeweiligen Hersteller müssen diesen Patch wiederum in ihr Betriebssystem einbauen und dann selbst ein Update veranlassen. Das wird höchstwahrscheinlich nicht bei allen Anbietern bzw. auch nicht bei allen Geräten selbst der fleißigsten Anbieter passieren.
Aus diesem Grund bleibt wohl vorerst als Lösung nur noch die Nutzung anderer Browser.

Kann man den AOSP-Browser ohne Nachteile deinstallieren?
Das wäre vermutlich die sicherste Variante, allerdings bin ich mir nicht sicher, ob das nicht ggf. große Nachteile nach sich zieht, weil der Browser evtl von anderen Android Apps benötigt wird o.ä.
Was sagen unsere Leser dazu?

Auch mit Firefox 31 nun keine selbstsignierten SSL Zertifikate mehr unterstützt

1. August 2014 Posted by Manuel Nientit

Quick-Tipp Lotus Notes Traveler IBM Domino
Die Luft für Nutzer selbstsignierter SSL Zertifikate wird immer dünner.
Schon vor einiger Zeit berichteten wir darüber, dass Windows Phone keine selbst signierten Zertifikate unterstützt. Diese Problem ist nun bei einem anderen Kunden wieder aufgetaucht, der nun auch mit einem Nokia Lumia experimentieren wollte. Erschwerend war hier nun aber, dass auch der Zugriff auf die Traveler-Weboberfläche mit Firefox plötzlich nicht mehr möglich war. Statt der erwarteten Anmeldemaske erschien eine Fehlermeldung, die einem mitteilte, dass das Zertifikat ungültig sei. Keine Möglichkeit mehr, die Meldung zu ignorieren bzw. eine Ausnahme hinzuzufügen.

Dazu gibt es seit gestern eine Technote bei IBM.
Es gibt offenbar mit Firefox 31 einen neuen Validierungsalgorithmus für SSL-Zertifikate, der das neue Verhalten zeigt. Diesen kann man über die Konfiguration (about:config) deaktivieren, um das alte Verhalten zurück zu bekommen. Das ist natürlich aus mehreren Gründen keine langfristige Lösung:
  • Der alte Algorithmus wird mit der Zeit aus Firefox ausgebaut werden (laut Mozilla Wiki), so dass man sich dem Problem mittelfristig wieder wird stellen müssen.
  • Es ist zu viel Aufwand, wenn man das nicht zentral steuern kann - was vermutlich nicht bei allen Unternehmen der Fall ist
  • Es bedeutet einen vermutlich sichereren Algorithmus mutwillig zu deaktivieren, weil man...
  • ...nicht das ohnehin sicherere, aber kostenpflichtige/-günstige, vertrauenswürdige Zertifikat kaufen möchte.
-> Also besser gleich ein Zertifikat einer vertrauenswürdigen CA ausstellen lassen.

BTW: Die von IBM vorgeschlagene "Lösung" funktioniert .

Neue Traveler Client App 9.0.1.1 erschienen

11. Juli 2014 Posted by Manuel Nientit

Lotus Notes Traveler
Wie Mat Newman in seinem Blog ganz richtig bemerkt, ist dieses Release nicht einfach nur ein Punkt-Release. Es ist eine Generalüberholung mit neuen Funktionen und ganz neuer Benutzerführung.


Die nachfolgende 29(!)-seitige Präsentation zeigt mit sehr schönen Screenshots, was sich geändert hat:

Um Missverständnissen vorzubeugen: Damit geht kein neues Traveler Server Release einher. Wer diese neue App also haben möchte, muss sie sich im Google Play herunterladen und ggf. manuell auf seinem Traveler Server einbinden.

Domino nicht von Heartbleed Bug betroffen

10. April 2014 Posted by Manuel Nientit

IBM Domino
Im Moment geht der Heartbleed Bug durch die Presse und beunruhigt viele Leute - zu Recht wie mir scheint.
Domino-Administratoren können aber beruhigt sein, da die fragliche, lückenhafte OpenSSL Bibliothek keine Anwendung findet, wie IBM nun bestätigt

BlackBerry kündigt neue Geräte an

28. Februar 2014 Posted by Manuel Nientit

Mobile Device Management
BlackBerry hat auf der MWC nun auch ein paar Neuerungen angekündigt.
Zum einen soll es zwei neue Geräte geben:
  • Das Z3 sortiert sich anscheinend im Niedrigpreis-Sektor ein. Ob es auch auf dem europäischen Markt erscheint, bleibt abzuwarten
  • Das Q20 führt offenbar die von den "alten" BlackBerries bekannten Hardwaretasten für Telefonannahme etc. wieder ein. Ich bin zwiegespalten...
BBM soll eine neue, sicherere Verschlüsselung bekommen - was in Zeiten der Übernahme eines gewissen IM-Dienstes durch ein gewisses Soziales Netzwerk vielleicht genau die richtige Ankündigung ist.

Dass der BES 12 offenbar nun endlich auch BES 5 und 10 vereinheitlichen soll, kommt um gefühlte 10 Jahre zu spät. Aber die Unterstützung für Windows Phone ist auf jeden Fall eine gute Sache.
Das aktualisierte Lizenzmodell sieht zumindest einmal übersichtlicher aus.

Es tut sich so Einiges .

iOS Keylogger Sicherheitslücke ist eigentlich eine allgemeingültige Sicherheitslücke

26. Februar 2014 Posted by Manuel Nientit

Mobile Device Management
Aktuell wird relativ breit und unter Anderem bei heise über eine Sicherheitslücke im iOS berichtet, die es einer App ermöglicht, alle Keyboard/Touch-Eingaben abzufangen und an einen Server zu senden. Möglich ist das wohl dadurch, dass eine App, die im Hintergrund läuft, alle Eingaben abfangen kann. Das ist natürlich nicht schön, aber auch alles nur weder neu noch auf iOS beschränkt.

Ähnliches gibt es auch für Android - zum Beispiel als Proof-of-Concept hier - wo das zum Beispiel dadurch ermöglicht wird, dass es relativ einfach ist, eine App zu fälschen und um eigene Funktionen zu erweitern. Das geht meines Wissens nach gar nicht unähnlich auch wiederum für iOS.
Über die Zahl der bekannten - und noch mehr der nicht bekannten - Keylogger im Windows muss man wahrscheinlich gar nicht mehr reden...

Da offenbar kein oder zumindest die wenigsten Betriebssysteme in der Lage sind, Keylogger in der ein oder anderen Weise zu unterbinden, hilft eigentlich nur einer sehr genaue Kontrolle der Anwendungen, die auf den Endgeräte installiert werden dürfen bzw. die Installation weiterer Apps zu unterbinden. Noch mehr hülfe (Hah - Konjunktiv II ) natürlich die Verwendung eines sicheren Betriebssystems...

Damit erweitert sich unsere MDM-Feature-Wunschliste um ein paar weitere Punkte:
  1. Zentrale Verteilung von benötigten oder erlaubten Apps
  2. Verbot solcher, die nicht den obigen Kriterien entsprechen
  3. Steuerung der Berechtigungen der Apps auf App-Ebene - sehr enttäuschend, dass der BES diesbezüglich einen weiten Schritt zurück getan hat und das nicht mehr anbietet
  4. Konkret für diesen Fall u.U. Einführung einer weiteren Berechtigungsgruppe "Hintergrundaktivität" - ich weiß, hier spinne ich vor mich hin , denn soweit ich weiß, gibt es nicht einmal ein OS, das diese Funktion hätte, geschweige denn ein MDM.
Erwähnte ich schon, dass die private Nutzung von Smartphones im Unternehmenskontext - vorsichtig ausgedrückt - kritisch zu sehen ist?
Das wird zu meinem persönlichen "Ceterum censeo..."

Kritische SSL-Sicherheitslücke in iOS 6 und 7

24. Februar 2014 Posted by Manuel Nientit

Da ich gerade so gut in Fahrt bin und es zum Thema meines vorangegangenen Artikels passt, kommt hier noch eine Eilmeldung zu einer Sicherheitslücke in iOS 6 & 7:
Die aufmerksamen Leser von Heise werden sie schon kennen. Den anderen sei sie dringend ans Herz gelegt.

Die bekannt gewordene Sicherheitslücke in der Verifizierung von SSL-Zertifikaten ermöglicht es wohl "Dritten in einer privilegierten Netzwerkposition", was vermutlich das gleiche LAN bedeutet, SSL-"gesicherte" Kommunikation abzufangen, entschlüsseln und ggf. zu ändern.
Ein Update auf 7.0.6 respektive 6.1.6 sollte schnellstmöglich durchgeführt werden.