Beiträge von rugk

Eine Firma namens AppBugs hat eine App entwickelt, welche bekannte Apps anhand einer Datenbank auf Schwachstellen untersucht und anzeigt, welche Apps verwundbar sind.
Vor kurzem haben sie viele bekannte Apps gefunden, beispielsweise Slack, Soundcloud und Kobo, welche unlimitierte Passwort-Eingaben zulassen und somit Brute-Force-Angriffe ermöglichen. Nur die Hersteller der Apps Pocket, Wunderlist und Dictionary haben die Sicherheitslücke behoben.
Die App ist aktuell nur für Android verfügbar. Eine App für iOS ist nach Angaben des Unternehmens in Entwicklung.
Allerdings scheint mir deren Geschäftsmodell etwas suspekt, denn sobald man in der App Details zu einer Sicherheitslücke anzeigen will, soll man dazu per InApp-Kauf Geld ausgeben.
Soweit ich weiß kann man diese Details jedoch auf der Webseite des Unternehmens gratis ansehen.

@Steffen
Die Icons wurden in einem der letzten Builds nochmal redesinged. Wohl aufgrund von vielen Nutzerbeschwerden wurden sie etwas "entflacht" und sehen jetzt nicht mehr allzu platt gequetscht aus.
Der Mülleimer wurde dabei natürlich auch neu gestaltet.

Computerguard.de ist jetzt auch im Addon HTTPS-Everywhere mit vertreten. Was dies bringt und was HTTPS-Everywhere überhaupt ist, erkläre ich in diesem Post.

Das Problem
SSL bzw. TLS-Verschlüsselung an sich ist ein solider Schutz. Doch standardmäßig bauen Browser eine HTTP-Verbindung zu jeder Seite aus. Die Seite kann dann über eine Weiterleitungsaufforderung (302-Redirect in diesem Fall) den Browser anweisen, zu der HTTPS-Version zu wechseln. Wenn dies geschieht und der Browser dies umsetzt wird eine verschlüsselte Verbindung aufgebaut.
Problematisch ist hierbei nur ein Fakt: Die gesendete Umleitungsaufforderung wird über HTTP gesendet und kann somit abgefangen werden. Auf diese Art kann ein Angreifer die Verbindung abfangen und diesen Redirect nicht weiterleiten. Damit die Webseite jedoch normal angezeigt wird, muss der Angreifer die Webseite logischerweise abrufen - dies kann er dann ganz normal über HTTPS erledigen.
Sein Angriff besteht jedoch jetzt darin beim Erhalt der echten Webseite diese einfach unverschlüsselt (also über HTTP) weiterzuleiten. Dann verhält er sich einfach wie ein Proxy - er nimmt unverschlüsselte Daten an, analysiert, fälscht, speichert oder tut was auch immer mit Ihnen und leitet sie dann verschlüsselt weiter. Der Server bemerkt nichts da er ja eine ganz normale HTTPS-Verbindung vor sich hat und der Benutzer kann sogar mit einem gefälschten Schloss-Symbol als Favicon getäuscht werden.

HTTPS-Everywhere hilft
Dagegen hilft eigentlich nur eins: HTTPS (am Besten gleich beim ersten Aufruf der Seite) benutzen. Denn dann werden erst gar keine Daten über eine normale HTTP-Verbindung gesendet. Neben an- neben anderen Techniken, wie HSTS, welches wir hier auch benutzen - hilft dafür vor allem auch ein Addon: HTTPS-Everywhere.
Manchen mag es ein Begriff sein und die simple Aufgabe des Add-ons ist es möglichst viele Seiten die HTTPS unterstützen direkt bei der ersten Verbindung mit HTTPS aufzurufen. Dies klingt simpel und ist es auch - einmal installiert vergleicht es jede aufgerufene Webseite mit einer internen Liste und wenn die Webseite dort als HTTPS-unterstützend enthalten ist, wird die Anfrage entsprechend abgeändert.

Computerguard ist dabei
Das Add-on ist Open-Source und so kann man bei GitHub seine eigenen Umleitungsregeln einreichen. Und damit alle Besucher die Computerguard besuchen auch davon profitieren können, haben wir auch unsere Domain hinzugefügt. Die aktuelle Regel könnt ihr auf einer Webseite sehen.
Wer das Add-on downloaden möchte kann dies auf der entsprechenden Webseite tun. Es ist für Firefox, Chrome, Opera und Firefox für Android verfügbar.
Bei Computerguard.de sieht dies dann so aus:

Bei den Versionen ab Firefox 39 und Thunderbird 38.1 wurde dieser Fehler übrigens gefixt.

Das macht ja auch kein Mitarbeiter persönlich. Sondern logischerweise die Firma.
Außerdem geht es auch nicht um "Mut" - Avira hat dies nur gemacht um die eigene Malware-Erkennung zu "belegen" bzw. zu rechtfertigen. Hätten sie diesen Gerichtsbeschluss nicht erhalten hätten sie die Erkennung dieser Software entfernen müssen (oder/und evt. ordentlich Schadensersatz zahlen müssen).
Sicher würde ESET sich auch so verteidigen.
Deshalb versucht ESET ja auch solche Erkennungen klar zu begründen bzw. zu belegen. Denn einen Rechtsstreit möchte man logischerweise nicht unbedingt.
Aber genau durch diese rechtliche "Gefahr" ist die Erkennung bzw. Einordnung von/als PUA nicht immer leicht und viele AV-Anbieter erkennen deshalb solche Software eher selten. ESET und Malwarebytes sind dabei allerdings ganz gut und erkennen viele solcher PUA.

Das OS kann da nicht viel tun - das ist eben wie Malware. Das muss erkannt werden von Software. Deswegen ja auch dieses Urteil, welches zumindest in diesem Einzelfall klar gestellt hat, dass Avira diese Software erkennen darf.
Es geht ja um PUA - eine Sorte kann man zum Beispiel auf diese Weise vermeiden.

Zitat von xfire09

Qihoo lässt Test Laboren abgeänderte Versionen zukommen um besser bei Test abzuschneiden

Diesbezüglich gab es bei uns übrigens auch einen Thread: Qihoo fälscht AV-Testergebnisse | Computer Security Community

Zitat von xfire09

Zu Recht

Update: Schummelei in AV-Vergleichstests | it-administrator.de

Ja, siehe auch den Thread dazu: Qihoo fälscht AV-Testergebnisse | Computer Security Community

Gerichtsurteil gegen Adware-Downloads: Antivirenprogramme dürfen warnen | heise Security

Einfache Kurz-Erklärung:
HTTP Public Key Pinning: Es wird sichergestellt, dass das Zertifikat, welches den Abruf unserer Seite via HTTPS ermöglicht, das richtige ist. Beim ersten Aufruf unserer Seite werden deshalb Informationen zum verwendeten Zertifikat gespeichert um später nachschauen zu können ob es immer noch das gleiche ist. Sollte es später nicht mehr das gleiche sein, stimmt da was nicht...
Content Security Policy: Wir definieren (mehr oder weniger strikte) Regeln, von wo Teile unserer Webseite geladen werden. (Von www. hackwebsite.example.com darf bzw. kann zum Beispiel nichts geladen werden :))

Vielleicht hilft das weiter.

Seit einigen Wochen benutzt Computerguard nun zwei weitere Sicherheitsfeatures. Eines erhöht, die Sicherheit gegenüber XSS-Angriffen und eines erhöht die Sicherheit der HTTPS-Verbindung.
Wir konnten die Features nun einige Zeit testen und optimieren und möchten sie in diesem Thread einmal vorstellen.

[size=18][COLOR=#004F55]HTTP Public Key Pinning (HPKP)[/COLOR][/SIZE]
Nach der allgemeinen Einführung von HTTPS und der Aktivierung von HSTS folgt nun ein weiterer Schritt, der die Sicherheit der TLS-Verbindung erhöhen sollte: Public Key Pinning.

[size=14]Umsetzung[/SIZE]
Bei HTTP Public Key Pinning wird - wie bei HSTS - ein spezieller HTTP-Header gesendet. Dieser enthält eine Prüfsumme (den SHA-265-Hash) des öffentlichen Schlüssels unseres SSL-Zertifikates und wird vom Browser gespeichert.
Bei jedem weiteren Aufruf von Computerguard.de wird dann der Hash des gesendeten Zertifikates mit dem Hash des gespeicherten (sozusagen gecachten Hashs) verglichen.
Wenn dies fehlschlägt erhaltet ihr folgende Fehlermeldung (hier mit Firefox):
AP_dexxmor1.png
Um es möglich zu machen, dass Zertifikat (zum Beispiel, wenn es kompromittiert wurde) ohne eine Fehlermeldung auszutauschen, mussten wir außerdem einige Backup-Zertifikate erstellen und auch deren Hashs angeben.
Bei uns ist die Zeit, die ein solcher Header gültig bleibt, auf 90 Tage gesetzt. Es wird also erst nach 90-Tagen ein (möglicherweise) anderer Header mit einem oder mehreren neuen Hashs akzeptiert.

Hintergrund
Der Sinn des Ganzen ist vor allem die Angriffsmöglichkeiten einer bösartigen Zertifizierungsstelle (Certification Authority) einzuschränken. Normalerweise kann jede im Browser enthaltene Zertifizierungsstelle für jede Webseite SSL-Zertifikate ausstellen, die problemlos akzeptiert werden. Da im Browser jedoch sehr viele Zertifizierungsstellen enthalten sind, ist es schwierig da wirklich allen zu 100% zu vertrauen, denn jede einzelne dieser Zertifizierungsstellen könnte MITM-Angriffe durchführen.
Mit HPKP muss nun nur noch der ersten Verbindung vertraut werden - alle weiteren Verbindungen werden dann einem extra Sicherheitscheck unterzogen. Ein Angreifer müsste also fortlaufend alle HTTPS-Verbindungen abfangen und manipulieren um keine Fehlermeldung zu erzeugen.

Und das funktioniert wirklich?
Ihr traut unseren Aussagen oder der Technik dahinter nicht? Sehr gut, denn ihr könnt es selber testen. Dank eines mehr oder weniger erwünschten Features einiger AVs könnt ihr dies sogar ganz einfach nachvollziehen. Zuvor müsst ihr in eurem Browser jedoch in den allermeisten Fällen eine Ausnahmeregelung außer Kraft setzen, die das Vorgehen solcher AVs normalerweise erlaubt. Für Firefox gibt es unter diesem Link eine Anleitung, wie man dies macht.
Wenn alles vorbereitet ist, könnt ihr beginnen:

1. Ruft Computerguard.de auf um den Header zu empfangen. (da ihr diese Seite gerade lest ist es ziemlich wahrscheinlich, dass ihr den Header schon habt)
2. Aktiviert SSL-Scanning, das "Prüfen verschlüsselter Verbindungen" oder eine ähnliche Option, die bei eurem AV den Traffic von verschlüsselten (HTTPS-)Verbindungen prüft. Möglicherweise müsst ihr dafür den Browser neu starten.
3. Ruft im Browser erneut computerguard.de auf. Jetzt sollte der Versuch eures AVs die HTTPS-Verbindung zwischen computerguard.de und eurem Browser abzufangen fehlschlagen und der Browser sollte eine entsprechende Fehlermeldung anzeigen. (wie die bei "Umsetzung" angezeigte)

Beachtet werden muss nur, dass dies aktuell nur von Firefox 35 oder höher und Chrome 38 oder höher unterstützt wird. Im neuen Browser von Windows 10 - Edge (Codename: Project Spartan) - wird dies möglicherweise auch implementiert.
[size=18]
[COLOR=#004F55]Content Security Policy (CSP)[/COLOR][/SIZE]
Die Content Security Policy ist prinzipiell nur eine Schutzmaßnahme gegen die unerlaubte Anführung und Einbettung von "fremden" Inhalt. Effektiv verhindert sie somit XSS-Attacken.

Funktionsweise
Auch der CSP-Header ist prinzipiell nur eine Anweisung an den Browser. Er enthält Regeln welche Objekte der Webseite von welcher Quelle geladen werden dürfen.
So kann man beispielsweise festlegen, dass Javascript nur von der eigenen Domain geladen werden darf (computerguard.de also) und nicht innerhalb von HTML-Dokumenten (mit <script>...</script>) verwendet werden darf.
Vor allem letzteres hilft gegen XSS-Attacken, bei denen oft wird Webseiten fremdes Javascript "unterzuschieben". Aber nicht nur Javascript kann blockiert werden, sondern auch CSS, Bilder, IFrames und mehr.

Einschränkungen
Jedoch bedeutetet dies natürlich auch, dass alle Javascript-Teile in .js-Dateien ausgelagert werden muss. Ebenfalls muss standardmäßig auf die Eval-Funktion von Javascript verzichtet werden. Da XenForo beides aktuell allerdings nicht bietet, mussten wir diese Regeln etwas lockern.
Außerdem mussten wir weitere Außnahmen hinzufügen, beispielsweise damit externe Bilder angezeigt werden können, die eingebetteten Videos erfolgreich laufen oder damit das bei der Anmeldung verwendete reCaptcha von Google funktioniert.

[COLOR=#004F55][size=18]Reporting[/SIZE][/COLOR]
Sowohl HPKP als auch CSP haben jedoch beide ein sehr interessantes Feature. Verstöße gegen die Regelen (also beispielsweise eine Einbettung von fremden Javascript bei CSP oder einen falschen Zertifikathash bei HPKP) können von den Browsern an eine Webseite zurückgemeldet werden.
Wir benutzen dafür report-uri.io von Scott Helme, welches nach dem Teil des Headers benannt ist (report-uri: ), der dem Browser meldet, an welche Adresse er solche Verstöße melden soll. Dieses bietet eine einfache Benutzeroberfläche und wir brauchen somit kein eigenes System dafür aufzubauen.
Natürlich werden wir die Reports regelmäßig überprüfen und wenn es etwas auffälliges gibt euch berichten.

[COLOR=#004F55][size=18]Übrigens...[/SIZE][/COLOR]
Beide Features laufen schon mehrere Wochen auf dieser Webseite. In dieser Zeit hatten wir insbesondere den CSP-Header immer wieder verbessert, da es doch einige Dinge gab, die von anderen Webseiten eingebettet wurden.
Aktuell sollte alles wie erwartet funktionieren. Wenn dies bei einer Funktion nicht der Fall sein sollte, schaut in der Konsole eures Browsers (meist mit F12 aufrufbar) nach (CSP-)Fehlermeldungen und meldet diese an einen Admin oder antwortet in diesem Thread.

Bezüglich ESET werden dort - soweit ich weiß - die URLs von besuchten Webseiten nicht an Cloud-Server gesendet. Die Phishing-Prüfung wird lokal ausgeführt mit einer Datenbank, die alle 15 Minuten aktualisiert wird.
Eine Cloud-basierte Prüfung findet mittels ESET LiveGrid statt. Dies kann jedoch teilweise (z.B. nur das Senden von Samples oder statistischen Informationen an ESET) oder vollständig (gar keine Cloud-Prüfung) deaktiviert werden. Zumindest letzteres wird natürlich nicht empfohlen. Außerdem gibt es bei ESET LiveGrid eine Ausschlussliste von Dateitypen, die schon in der vorkonfigurierten Version viele Dateitypen enthält, welche potentiell persönlichen Daten enthalten könnten (z.B.: .doc, .docx, .rtf). Weitere Dateitypen (wie beispielsweise .txt) können manuell hinzugefügt werden.
Inwieweit Informationen über das System und OS gesammelt werden kann ich nicht sagen, jedoch gibt es im englischen ESET-Forum einen Thread über den erwähnten AV-Comparatives-"Test" - unter anderem wird klar gesagt, dass ESET nur anonymisierte Daten sammelt, die keine persönlich identifizierbaren Informationen enthalten.

Ein interessanter Hinweis zu dem Artikel von Emsisoft: So wie es dort dargestellt wird, werden wohl MD5-Hashs zum Überprüfen der Malware in der Cloud verwendet. Dies hat zwar evt. den Vorteil einer geringeren Beeinträchtigung der Privatsphäre allerdings könnte man wohl den Cloud-Check von Emsisoft umgehen, da MD5 nicht mehr als sicher gilt. (Mehr Infos)

Edit: Bezüglich der URL-Prüfung hat im englischen ESET-Forum dazu nochmal ein Nutzer nachgefragt. So wird die URL wohl doch "wenn nötig" auch online geprüft. Mehr Infos hier

@Steffen
Zumindest wird ja gesagt "erlaubte" - also in der Vergangenheitsform.

Interessant ist noch zu sehen was ESET dazu schreibt. Drei Dinge sind dabei anzumerken:

1. Es war nur die Emulation für eine spezielle Malware-Familie betroffen, nicht die allgemein genutzte. Allerdings bin ich mir nicht sicher wann welche Emulationsmethode genau benutzt wird - es kann durchaus sein, dass auch die spezielle Emulationsmethode für die eine Malwarefamilie immer genutzt wird.
   
2. Der Bug wurde nach 3 Tagen gefixt.
3. In den Pre-Release-Updates war der Bug schon vor der Bug-Meldung nicht enthalten.

Zitat

Statt die Nutzer zu schützen erlaubte NOD32 von Eset es Angreifern, die Rechner der Opfer komplett zu übernehmen. Das Update, welches die Lücke schließt, sollte schleunigst eingespielt werden.

Der Virenscanner NOD32 von Eset konnte von Angreifern missbraucht werden, Schadcode mit Systemrechten auszuführen. Die Sicherheitslücke wurde nun von Googles Project Zero bekanntgegeben, nachdem Eset sie bereits geschlossen hatte. Betroffen sind Versionen von NOD32 auf Windows, OS X und Linux, da die fehlerhafte Sandbox auf allen Betriebssystemen ähnlich funktioniert.

NOD32 erlaubt das Kapern von Rechnern | heise Security

Ganz am Ende des Artikels kommt der wichtigste Fakt: Ihr solltet sicherstellen, dass das mindestens VSD-Update 11824 oder höher installiert ist.

@Lucien_Phoenix
PM gesendet.

Würde dir auch ein 20%-Gutschein auf den Standard-Preis im ESET Shop reichen?

Nach heise Security soll "Duqu 2.0" auch Atomverhandlungen im Visier gehabt haben, weshalb jetzt die Schweiz und Österreich gegen Unbekannt ermitteln.

Dank einer US-Behörde bekam die belgische Polizei Informationen von WhatsApp-Kommunikationen von wohl 16 Verdächtigen (in 21 Razzien) belauscht. Natürlich nur zur Terrorabwehr.
Allerdings gibt es ein Problem: Offensichtlich hat dies nichts genutzt, denn alle 16 Personen sind wieder auf freien Fuß. Also wohl doch kein Terroranschlag?

Aus technischer Sicht ist durch die Whats-App-Verschlüsselung jetzt nur noch die Frage wann diese Spionage-Aktion durchgeführt wurde, denn davon hängt schließlich ab ob und was für ein Verschlüsselungssystem die Angreifer knacken oder umgehen mussten.

Zitat

Die belgische Polizei hat mehrere Razzien gegen Terrorverdächtige durchgeführt, nachdem die amerikanischen Kollegen den Ermittlern beim Abhören von WhatsApp-Nachrichten halfen.

US-Behörden belauschen WhatsApp-Kommunikation | heise Security

Zitat

Apple drängt Entwickler dazu, in ihren Programmen für iOS 9 und OS X 10.11 ausschließlich auf eine verschlüsselte Übertragung per HTTPS zu setzen. HTTP-Verbindungen müssen begründet werden – und sind offenbar nur temporär vorgesehen.
[...]
Der Schritt deutet an, dass Apple zu einem späteren Zeitpunkt nur noch Apps zulässt, die ausschließlich HTTPS nutzen.

Apple will HTTP-Verbindungen aufs Abstellgleis schicken | Mac & i

Zitat

Entwickler von Apps für iOS und OS X sollten "so schnell wie möglich" auf sichere Verbindungen per HTTPS wechseln, empfiehlt Apple. Das Unternehmen könnte die Verschlüsselung gar für die Aufnahme im App Store erzwingen.
[...]
Auch bestehende Software solle schon jetzt möglichst HTTPS verwenden. [...] Mit ATS soll es ausreichen, lediglich die benötigten URLs anzugeben, um die eigentliche Absicherung kümmert sich das Framework.
[...]
ATS unterbindet dabei [...] HTTP. Um dies dennoch [in iOS9 und kommenden OS X 10.11] benutzen zu können, muss die entsprechende Verbindung explizit angegeben werden.

iOS und OS X: Apple könnte HTTPS für Apps erzwingen - Golem.de

Hier mal ein Querverweis bezüglich der Beta von Acronis True Image 2016:
Vorstellung - Acronis True Image 2016 (Ultimate) Beta | Computerguard Security Community
[size=12](Thread von @xfire09)[/SIZE]