Deutsch | English
Dieser Blog enthält keine offiziellen Aussagen von CERT.at, sondern persönliche Meinungen einzelner Mitarbeiter.
Zusatzinformationen zum Interview im Standard
16. Juli 2014

Wir freuen uns (fast) immer, wenn wir in Medien zitiert werden, und wir damit eine deutlich breitere Masse erreichen, als nur über unsere direkten Kanäle (Webseite, RSS, Mail, Twitter).

Nur: Interviews müssen meist recht schnell gehen, Journalisten arbeiten täglich mit harten Deadlines und auf Papier gibt es beschränkten Platz und keine Hyperlinks.

Daher will ich hier ein bisschen Kontext zum Interview geben, das heute (16. Juli 2014) in der toten-Bäume Version von "Der Standard" erschienen ist. (Die WebStandard-Variante ist hier.)

Zum Begriff CERT:

CERT wird üblicherweise als "Computer Emergency Response Team" gedeutet, ist aber ein generischer Begriff für ein Team, das sich um die Behandlung von Sicherheitsvorfällen in Computernetzen kümmert. "CERT" selber ist in den USA eine eingetragene Marke des Ur-CERTs an der Carnegie-Mellon Universität. Dort wird lieber gesehen, wenn man "CSIRT - Computer Security Incident Response Team" als generische Bezeichnung für CERTs verwendet.

Es gibt global viele CERTs (Listen von Dachverbänden sind hier: FIRST, Trusted Introducer), auch in Österreich deklarieren sich einige Teams als "CERT". Ein Satz in der Art von "Das CERT sagt, ..." ist daher unklar formuliert. Das ist wie "Die Feuerwehr sagt, ...": Es mag vom Kontext her klar sein, welche denn gemeint ist, aber besser ist, wenn qualifiziert wird, welche Feuerwehr gemeint ist.

CERT.at ist das nationale CERT für Österreich. Wir fungieren als Auffangbecken für alle Vorfälle in Österreich, die nicht von Sicherheitsteams behandelt werden, welche näher am Problem sind.

Schutzniveau:

Zur Frage, welche Schutzmaßnahmen gegen Abhören man treffen soll, will ich hier nochmal betonen, das dies primär von zwei Faktoren abhängt: a) Was ist der Wert der Informationen, die man schützen will? und b) Gegen welchen Angreifer (und damit: welche Fähigkeiten hat dieser) will man sich wehren?

Fast jede Verteidigungsmaßnahme hat Kosten (Geld, Zeit, Bequemlichkeit, ...): Es kann somit kein global gültiges Optimum an Schutz angegeben werden, das kann man immer nur im Einzelfall entscheiden.

Tipps gegen den NSA-Staubsauger:

  1. Eigene Datenspuren: Was auch immer man im Netz offen publiziert, kann natürlich auch von den Geheimdiensten ausgewertet werden.
  2. Vertraue keine wichtigen Daten Firmen an, die gesetzlich dazu verpflichtet sind, mit der NSA zu kooperieren. (Nebenbemerkung dazu: es gibt gerade ein Gerichtsverfahren in den USA, wo ein dortiges Gericht auch Daten von Microsoft haben will, die in EU Datacentern gelagert sind)
  3. Möglichst wenig unverschlüsselt kommunizieren: Mailversand und -empfang nicht im Klartext, sondern mit TLS. (Links dazu etwa: 1+1, GMX; das sollte 2014 jeder Email-Provider unterstützen). Detto bei möglichst allen Webdiensten die https-Version nutzen. Auch bei der Wahl von Chatdiensten kann man es der NSA einfach -- oder eben schwieriger machen.

Das ist alles kein kompletter Schutz, aber Geschenke an die NSA müssen nicht sein.

Wie transportiert man einen Diamanten:

Die Überlegung stammt nicht von mir, sondern vom Transport des Cullinan Diamanten nach England. Wenn der Trick aufgeht, ist das eine geniale Lösung. Aber wehe, wenn der Gegner die Finte durchschaut hat: dafür gibt es dann kein Sicherheitsnetz.

Autor: Otmar Lendl

[CERT.at #300000]: Die nächste runde Ticketnummer
17. Juni 2014

Es ist wieder soweit: unser Ticketsystem hat einen Meilenstein erreicht: jetzt stehen wir bei 300.000 Tickets:

cert-tickets-300000-small

Ein paar Anmerkungen will ich auch dieses mal anbringen:

  • Die Entwicklung unsere Zahlen hängen nicht nur vom Zustand des Internets in Österreich ab, sondern auch von der Verfügbarkeit und Qualität unserer Datenquellen. Ein Sprung in den von uns verarbeiteten Meldungen zu einem Botnetz kann schlicht an der Verfügbarkeit von Daten zu diesem Botnetz liegen, nicht aber an dessen Verbreitung.
  • Die Gesamtzahl der Tickets sagt auch nur bedingt etwas über den Arbeitsaufwand bei uns im Team aus: Ein simples Weiterleiten von Sinkhole-Daten an ISPs erfordert nur wenig menschliche Aufmerksamkeit, eine Bearbeitung eines Exploit-Packs auf einer Webseite aber hingegen schon: Trotz guter Tool-Unterstützung ist es aufwändig, genau nachzuforschen wo in der Webseite das böse JavaScript versteckt ist.
  • Weiters kann der Inhalt von Tickets sehr variieren: Ein "Lieber Domaineigentümer, deine Webseite ist verunstaltet" ist genauso ein Ticket, wie "Lieber ISP, die folgenden 500 IP-Adressen aus deinem Netz sind Teil eines Botnetzes".

Autor: Otmar Lendl

Hinweis für Debian-Benutzer bei OpenSSL Upgrade
6. Juni 2014

Again, Openssl was the centre of patching in the last two days. While Debian was quick to release a patched version, it seems like Debian forgot to restart some services which link against openssl (libssl) get restarted.

Here is how you can check with services use which version of openssl: root@hostname:~# lsof +c 0 | grep -w DEL | awk '1 { print $1 ": " $NF }' | grep libssl | sort -u

(...) freeradius: /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 openvpn: /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 python: /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

 

Next, you'll need to compare this list of programs against running services, for example:

root@host:~# ps auxww | grep python root 1960 0.0 7.2 65392 17956 ? S Jun03 1:11 python /usr/sbin/denyhosts --daemon --purge --config=/etc/denyhosts.conf

And finally restart these services again:

root@host:~# /etc/init.d/denyhosts restart [ ok ] Stopping DenyHosts: denyhosts. [ ok ] Starting DenyHosts: denyhosts.

Autor: L. Aaron Kaplan

FTP Zugangsdaten
30. Mai 2014

Wie Heise berichtet, hat das BSI/CERT-Bund viele Provider informiert, dass Zugangsdaten zu FTP-Accounts gefunden wurden.

Das betraf nicht nur Deutschland; die gleiche Quelle hat auch andere CERTs und Sicherheitsteams informiert. Wir bekamen die gleichen Daten wie unsere deutschen Kollegen, und auch wir haben für alle Datensätze zu unserem Verantwortungsbereich (IP-Adresse in Österreich und/oder .at-Domain) eine entsprechende Warnung an die ISPs geschickt.

Das waren rund 11 tausend Accounts, verteilt auf ~ 4300 IP-Adressen bei ~ 280 ISPs.

Zur Quelle dieser Daten können auch wir nicht viel öffentlich sagen, außer dass wir die Daten von einem Security-Researcher bekamen, der in der Szene sehr bekannt ist, und der (und das Team in dem er arbeitet) regelmäßig gute Telemetrie zu Cybercrime/Botnetzen liefert.

Ob er selber die Daten bei einer Aktion gegen ein Botnet gefunden hat, oder das nur über ihn gespielt wurde, wissen wir nicht.

Inzwischen gibt es diverses Feedback von den Netzbetreibern (international, als auch auf unsere Mails hin). Damit lässt sich etwas mehr zu diesem Fall sagen:

  • Der Datensatz enthält auch einige Credentials zu Hostnamen, die auf RFC1918-Adressen aufgelöst werden.
  • Wir gehen u.A. daher davon aus, dass die Zugangsdaten aus Konfigurationsfiles von FTP-Clients auf infizierten PCs stammen. Es ist bekannt, dass es zum Standard-Repertoire von Malware gehört, gespeicherte Passwörter diverse Programme auszulesen und an die Botnet-Zentrale zu melden.
  • Ein guter Teil der Credentials ist nicht (mehr) gültig
    • Oft genug landen Tippfehler in solchen "Saved Passwords"-Ablagen
    • Viele User löschen gespeicherte Passwörter nicht in der Client-Konfiguration, wenn sich am Server etwas ändert, oder sie den Zugang gar nicht mehr brauchen. Es sind daher auch in aktuellen Client-Configs genug obsolete Daten enthalten.
    • Ein Grund dafür kann auch der Wechsel des Hosters der Webseite sein: Wir haben den aktuell für den betroffenen Hostnamen zuständigen Betreiber angeschrieben, der FTP-Zugang könnte aber noch zum alten ISP passen.
    • Wir wissen nicht, wann diese Credentials von der Malware kopiert wurde. Das mag in einigen Fällen schon länger her sein.
    • Wir sehen keine rechtlich zulässige Möglichkeit, wie wir als CERT eine Gültigkeitsprüfung dieser Accounts machen könnten.
  • Einige dieser Accounts wurden benutzt um Webseiteninhalte zu manipulieren.

Autor: Otmar Lendl

Nächste >>
Email: reports@cert.at
Tel.: +43 1 5056416 78
mehr ...
"Zero-Day" Sicherheitslücke in Apple Quicktime
26. Juli 2014 Beschreibung Die ...
Sicherheitsprobleme mit OpenSSL
5. Juni 2014 | Das ...
mehr ...
Zusatzinformationen zum Interview im Standard
16. Juli 2014 | Wir freuen ...
[CERT.at #300000]: Die nächste runde Ticketnummer
17. Juni 2014 | Es ist ...
mehr ...
Jahresbericht 2013
Ein Resumee zur digitalen Sicherheitslage in Österreich.
Letzte Änderung: 2014/7/24 - 12:34:42
Haftungsausschluss