Deutsch | English
Dieser Blog enthält keine offiziellen Aussagen von CERT.at, sondern persönliche Meinungen einzelner Mitarbeiter.
In eigener Sache: kurze Service-Ausfälle heute, 28. Jänner 2015
28. Jänner 2015

Auch CERT.at ist von den aktuellen glibc/eglibc-Problemen betroffen, und wir müssen daher diverse Services neu starten. Dies kann zu kurzen Service-Ausfällen führen (jeweils im Bereich weniger Minuten). Es gehen dabei keine Daten (zb Emails) verloren, es kann sich nur die Bearbeitung etwas verzögern.

In dringenden Fällen können sie uns wie gewohnt telephonisch unter +43 1 505 64 16 78 erreichen.

Autor: Robert Waldner

Embedded Device Security - heute bez. diverser Geräte von Snom
13. Jänner 2015

Die Researcher von SEC Consult haben viele, viele Bugs - auch kritische - in VoIP-Telephonen der deutschen Firma Snom gefunden - das entsprechende Advisory findet sich hier.

Solche Embedded Devices finden sich mittlerweile zu Hauf, vom Privathaushalt bis zum Grossunternehmen. Und wir können nur darauf hinweisen, dass es gerade bei solchen "Black Boxes" eminent wichtig ist, sich um die Security zu kümmern - und das heisst nicht nur Ändern von Default-Passwörtern, sondern auch aktiv nach Software-Updates zu suchen. Im Gegensatz zu gängigen Betriebssystemen suchen solche Embedded Devices meist nicht selbst nach neuer Software, und haben auch keine Mechanismen, den Benutzer/Administrator auf Update-Bedarf hinzuweisen.

Je nach Hersteller ist das mehr oder weniger mühsam (Mailing Listen, RSS-Feeds, oder doch regelmässig auf der Homepage nachsehen) von Updates Kenntnis zu erlangen, und es kann auch sein, dass Hersteller den Software-Support irgendwann einstellen und einfach keine Updates mehr zur Verfügung stellen. In diesem Fall sollte man sich bereits im Vorfeld überlegen, wie dann mit der Situation umgegangen wird. Das kann von "ersetzen durch aktuelles Modell" über extra Wartungsvertrag bis zu netzwerktechnischer Abschottung reichen.

Autor: Robert Waldner

Regin
11. Dezember 2014

Wir haben in der Woche ab dem 24. November 2014 zum Thema Regin regelmäßige Status-Updates an die GovCERT Constituency (in unserer Rolle als GovCERT Austria), die potentiell betroffenen Sektoren (im Rahmen des ATC) und den CERT-Verbund verschickt.

Dieser Blogpost stellt unsere Timeline dieser Woche dar.

Initiale Meldung (Mo/Di)

Symantec hat am Sonntag einen Blogpost und einen Report zu einer sehr komplexen Malware/Cyberspionage-Kampagne publiziert.

Auf den Seiten 20 und 21 sind IOCs enthalten, nach denen man im eigenen Netz suchen kann; insb. die Suche nach verstecktem Code in "extended attributes" sollte relativ leicht machbar sein.

Das wurde natürlich von den Medien aufgegriffen, siehe etwa ORF.at, Ars Technica, DerStandard, recode, ...

Uns lagen zu diesem Zeitpunkt keine weiteren Information vor, wir haben aber bei unserem Kontakt bei Symantec nachgefragt, ob er mehr zu den Infektionen in Österreich sagen kann. Auf Grund der Zeitverschiebung zur US Westküste erwarteten wir hier aber keine schnelle Antwort.

Dann hat sich auch F-Secure gemeldet. Man beachte dabei den letzten Satz: "As always, attribution is difficult with cases like this. Our belief is that this malware, for a change, isn't coming from Russia or China." Das deckt sich auch mit anderen Gerüchten.

(Von F-Secure kam später dann noch eine weitere Analyse)

Auch Kaspersky steuert eine Analyse bei: Blog, Report. Zu den Problemen bei den Malware-Archäologie haben sie auch etwas geschrieben.

Wir untersuchen wie sich -- basierend auf den publizierten Informationen -- eine Infektion finden lassen könnte.

Inzwischen wurden schon Yara Rules publiziert. Wie sinnvoll diese Regeln sind, können wir nicht seriös bewerten. (Yara ist ein Werkzeug zum Suchen nach Mustern in Files. Quasi ein IDS für Files.)

Morgan Marquis-Boire, ehemaliger IT Security Guru bei Google (jetzt Citizen Lab), hat einen sehr spannenden Artikel zu Regin auf The Intercept publiziert: Der allgemeine Konsens ist, das hinter Regin die Geheimdienste aus UK/USA stecken, da diese Malware auch beim Einbruch bei der Belgacom 2013 verwendet wurde.

Mittwoch

  • Wir bekamen vor ziemlich genau einem Jahr einen Satz von IOCs aus dem Belgacom-Case von unseren Kollegen in Belgien. Wir haben diese am 2. Oktober 2013 an die GovCERT und ISP Community verteilt.

    Wirklich wertvoll sind diese IOCs jetzt nicht mehr (wenn sie das jemals wirklich waren), da der Täter hier hinreichend agil agiert und seine Parameter ändert. Wie sehr ein Suchen nach den aktuell verfügbaren IOCs jetzt purer Aktionismus ist (und nichts bringt), will ich aber nicht ernsthaft beurteilen.

  • Regin ist eigentlich "Yet Another APT". Vorher war es halt Snake, RedOctober, Miniduke, Careto, ...

    Ja, die Management-Attention ist jetzt da drauf, der Schutz des eigenen Netzes sollte aber nicht primäre reaktiv auf den Threat-des-Monats ausgerichtet sein, sondern generischer auf Anomalien im eigenen Netz schauen. Eigentlich sind die APTs, die schon in der Öffentlichkeit diskutiert werden, oft nicht mehr die wirklich große Gefahr.

  • Wir bekamen ersten Code, der die Crypto-Container anhand des eingebauten CRC-checks erkennen können sollte. Ich hab keine Ahnung, wie relevant das jetzt noch ist. Später hat dann G-DATA eine Version davon in Pyhton veröffentlicht.
  • Wir haben uns auch angeschaut, ob man gezielt nach den Extended Attributes suchen kann, die in den Berichten erwähnt werden. Hierzu hätten wird ein paar Ideen, das ganze wollen wir aber nicht groß verbreiten, da wir keine Datengrundlage für false-positive und false-negative Raten haben.
  • Achtung: Die Malware beschränkt sich nicht auf Windows. Manche Quellen sprechen auch von Linux und Solaris. (dort macht der Code zur Suche nach den Cryptocontainern auch Sinn)
  • Achtung2: Es wird im Kontext dieses Angreifers auch von Manipulationen von Routern geschrieben. Dazu kann ich nur auf ein Whitepaper des CERT-EU verweisen.
  • Achtung3: Wenn wir von NSA/GCHQ sprechen, dann sind auch BIOS-level Manipulationen von Servern/Workstations potentiell im Spiel. Da wird es dann schon sehr haarig. Auf der DeepSec letzte Woche (und beim November-Stammtisch) gab es dazu einen Vortrag. Da kann man die Paranoia noch weit treiben.

Donnerstag

  • Es gibt jetzt auch eine Warnung vom US-CERT. Dazu gab es auf Twitter die böse Meldung "That awkward moment when the US govt has to issue an alert about malware it & its allies likely created"
  • Unsere Kommunikation mit Symantec ergab folgende Erkenntnisse:

    Der Grund, warum im Symantec-Report Österreich als betroffenes Land geführt wird, ist dass deren AV-Produkte in den letzten Jahren Alerts generiert haben, die man jetzt Regin zuordnen kann. Neben völlig generischen Tags wurden diese Treffer auch mit "Backdoor.Trojan.GR" gekennzeichnet.

    Diese Alerts werden (unseres Wissens nach) vor allem dann generiert, wenn die Malware erkannt und abgewehrt wurde. Das sind also nicht notwendigerweise erfolgte Infektionen, sondern diese Hits sagen nur, dass diese Malware von der AV-Software gesehen wurde. Das mag heißen, dass die betreffende Organisation ein Ziel ist, oder aber auch nur, dass die Infektionen doch nicht nur das intendierte Ziel erreicht hatten. Auch Stuxnet wurde auch außerhalb des Zieles erkannt.

    (In der Diktion des Microsoft Security Intelligence Reports (SIR): es handelt sich um "Encounters", nicht um "Cleanups".)

    Es mag trotzdem für Symantec/Norton-Kunden Sinn machen, die eigenen Alert-Logs nach "Backdoor.Trojan.GR" zu durchsuchen. Die Aussagekraft der Ergebnisse davon ist aber sehr beschränkt.

Freitag

  • Es gibt immer mehr technische Hinweise / IOCs, etwa https://twitter.com/VXShare/status/537078969737428992, http://pastebin.com/0ZEWvjsC, ...

    Viele Leute schauen sich die publizierten Samples an und schreiben über ihre Erkenntnisse. Siehe etwa https://twitter.com/DidierStevens. Da wird noch einiges kommen.

  • Zu den Opfern gibt es immer konkreter werdende Gerüchte (Spiegel/OPEC, DerStandard/IAEA)
  • Wie ging die AV Branche mit dem Thema um?

    Manche haben schnell die Erkennung von Regin in ihre Produkte eingebaut, aber jetzt erst darüber berichtet. Es geht aber auch das Gerücht um, dass ein nicht-ganz-kleiner in der AV-Branche absichtlich keine Detection (jedenfalls für den Kundenkreis außerhalb US/NATO/5EYES/..) in seine Produkte eingebaut hat.

    (Mashable, Bits of Freedom, Trend Micro, ...)

  • Wie kann man jetzt aktuell nach dem Teil suchen?

    Man ist sich im großen und ganzen einig, dass viele der jetzt publizierten Samples und die daraus abgeleiteten Erkennungsregeln längst obsolet sind. Eine gezielte Suche nach Regin ist nur sehr beschränkt möglich, so etwa könnte man die Cyptocontainer oder die extended attributes als Ansatzpunkte nehmen.

    Um diesen Angriff im eigenen Netz zu finden (wenn man denn betroffen ist), kann man eigentlich nur auf die generischen Methoden zur Suche nach APTs verweisen. Wenn man aber schon auf Spionagesuche geht, dann sollte man die Augen in allen Richtungen offen haben.

  • Besteht dringender Handlungsbedarf?

    Jetzt im Dezember auch nicht mehr als am 21. November. Spionage von Staaten oder anderen Tätern aus politischen oder wirtschaftlichen Motiven gibt es nicht erst seit wenigen Wochen. Das ist seit Jahren eine Tatsache der wir uns stellen müssen.

    Die Enthüllungen rund um Regin können daher eigentlich nur der Anlass sein, dass man sich ernsthaft um seine IT Sicherheit kümmert, aber nicht der Grund dafür. Gründe gäbe es seit Jahren genug.

Autor: Otmar Lendl

Poodle-Attacke auch bei TLS
9. Dezember 2014

Die "Poodle"-Attacke ist ja nicht mehr wirklich neu (CERT.at Blog-Post dazu). Nun hat sich aber eine neue Facette dazu ergeben, wie das auch TLS-Verbindungen (Poodle war ja quasi ein SSLv3-Problem) betreffen kann.

Auf Golem.de wird das gut&ausführlich beschrieben.

Autor: Robert Waldner

Nächste >>
Letzte Änderung: 2015/1/28 - 09:26:26
Haftungsausschluss