Home      Themenübersicht / Sitemap      Notizen      Webmaster      
Newsletter AboVorläufige Gedanken, erfreuliches, beklagenswertes

 

Philipps Notizen - 2013

von Philipp Schaumann

An dieser Stelle werden Beobachtungen veröffentlicht, die ich interessant finde, ohne dass die Texte immer gleich in einen logischen größeren Zusammenhang eingereiht werden müssen.

 


Link-Konventionen:
Fette Links öffnen ein fremde Seite in einem neuen Fenster
Blau hinterlegte Links bleiben auf der sicherheitskultur.at

 


17.11.2013 - Google hat der NSA argumentatorisch den Weg bereitet

Leider hat Google (und alle anderen Social Networks) nicht nur argumentatorisch den Weg bereitet, sondern ungewollt auch technisch.

An anderer Stelle berichte ich, wie die NSA die Cookies dieser Dienste zur Identifizierung ihrer Zielpersonen nutzt - Stichwort QUANTUM.

In 2004 begann Google, die Inhalte der Mails auf gmail auszuwerten und dazu passende Werbung zu schalten. Schon damals argumentierte The Register dass sie damit eine Rutsche für die NSA gelegt hat. Register hat jetzt aus gegebenem Anlass auf die damalige Argumentation von Google hingewiesen: How Google paved the way for NSA's intercepts - just as The Register predicted 9 YEARS AGO.

D.h. Google argumentierte damals, dass sie die Mails der Kunden nicht wirklich lesen, denn 'lesen' wäre 'learn the meaning', d.h. setzt Sinnverständnis voraus. Google wertet die Mails der Kunden aber lediglich automatisiert mittels Computer-Algorithmen aus und damit gilt: 'Google will likely argue that its computers are not ‘people’ and therefore the company does not ‘learn the meaning’ of the communication'.

Und die NSA (und alle anderen Überwacher) machen genau das Gleiche: sie werten die Daten mit ihren Algorithmen aus. Es ist mittlerweile zweifelhaft, ob das mit Hilfe von Systemen wie Watson, die mittlerweile Menschen bei der extrem gefinkelten Quizshow Jeopardy schlagen, nicht sehr nah an Sinnverstehen kommt.

Weiter unten dann zu den Public-Private Partnerships zwischen den großen IT-Firmen und den Behörden wenn es um Überwachung der Bürger geht.

 




17.11.2013 - Die Wahl zwischen Werbung und Anonymität

In einem recht lesenswerten Blockbeitrag schreibt der Google Schweiz Mitarbeiter Mike Hearn über das Abhören der Synchronisation zwischen den Rechenzentren und was Google jetzt dagegen unternimmt. Dann kommt die Diskussion aber auch auf allgemeinere Themen, dass Google's Geschäftsmodell darauf beruht, dass sie die Inhalte im Klartext zur Verfügung haben und auswerten können. Wenn die Benutzer nur verschlüsselte Daten zu Google senden würden, so würde das Geschäftsmodell zusammenbrechen. Mike schreibt dann dazu:

Das stimmt natürlich für den jetzigen Stand des Internets sehr wohl. Überall wo ich bezahlen muss, bin ich geoutet. Die Sicherheitsbehörden sagen "Just follow the money". Ein Beispiel ist der Messaging Dienst Whatsapp (Chat zwischen Smartphones). Der ist nämlich fast kostenlos. Die Gebühr ist 1 USD pro Jahr. Das kann sich jeder leisten und ist bei 100 Mio Usern doch schon richtig Geld. Nachteil: die Betreiber (und damit die NSA) kennt von jedem Nutzer die Identität.

Feb. 2014:
An anderer Stelle habe ich einige Links zum Kauf von Whatsapp durch Facebook, was an Whatsapp alles problematisch ist und welche besseren Alternativen es gibt.

Und dass wir das nicht vergessen: Es geht nicht um die zumeist belanglosen Inhalte der Kurzmessages, sondern es geht um die sozialen Netze - wer kennt wen, das ist für die Behörden viel interessanter. Mehr zu Netzen an anderer Stelle. Hier gibt es mehr Infos über das Abhören des Datenvekehrs von Google u.a..

 



An anderer Stelle gibt es Ergänzendes zum Ransomware-Trend 2015/16


15.11.2013 - Cryptolocker Ransomware - aktualisiert 2015

Die Zeitungen berichten von der neuen Ransomware Cryptolocker. Erst dachte ich, na ja, da bin ich nicht betroffen, weil ich ja täglich eine Sicherung mache. Falsch.

Die Software ist nämlich unangenehmer als ich gedacht hatte. Es beginnt mit einer Infektion des Geräts (zumeist PC, aber auch Apple oder Smartphones sind dagegen nicht immun), zumeist erfolgt diese über das Anklicken eines Emails das angeblich von DHL oder einer anderen Firma kommt oder dem Besuch einer Website. Dann beginnt die Software erst mal damit, dass sie versucht, die Schattenkopien die das Windows Betriebssystem anlegt, zu löschen, damit eine Wiederherstellung daraus nicht möglich ist. Dann verschlüsselt sie jede einzelne Datei auf dem Rechner mit einem langen Schlüssel. Aber man hat ja hoffentlich die Daten auf einer anderen Festplatte gesichert.

Aber die Ransomware-Software geht dann auch an alle angeschlossenen Laufwerke (soweit sie über einen Laufwerksbuchstaben verfügen) und verschlüsselt diese auch. Damit würde so eine Softwar auch mein Backup erwischen, das ist nämlich normalerweise auch online. Und wer seine Cloud-Storage, z.B. Dropbox, über einen Laufwerksbuchstaben erreicht, dem wird auch noch die Cloud verschlüsselt.

Für Firmen verschlüsselt er auch die Shares auf die der infizierte PC über Laufwerksbuchstaben schreibend zugreifen darf. Die Verschlüsselung läuft langsam und das Programm meldet sich erst, wenn alles verschlüsselt ist. D.h. wenn erst die Hälfte von C: verschlüsselt ist und jemand dann Datensicherung macht, dann wird die bereits verschlüsselte Hälfte der Dateien in die Sicherung übernommen. Die Software hat auch noch ein paar andere unangenehme Tricks auf Lager.

Viele gute Details gibt es auf bleepingcomputer.com. Der Autor schreibt im Vorwort zu seinem Artikel, dass er bedauert, dass der Artikel sich wie eine Empfehlung liest, die ca. 300 Euro zu zahlen, aber für jemanden der keine verfügbare Sicherung mehr hat ist dies der letzte Strohhalm. Im konkreten Fall haben wohl viele der Opfer den Schlüssel für die Entschlüsselung bekommen (siehe der ausführliche Artikel), aber in anderen Fällen ist einfach nur das Geld kassiert worden. Das Problem mit dem Bezahlen für uns alle ist, dass dies natürlich das Geschäftsmodell bestätigt und wir es mit vielen solchen Angriffen zu tun haben werden, und viele werden gar nicht vorhaben, sich über das Aushändigen eines Schlüssels noch mal in die Gefahr zu begeben, erwischt zu werden.

D.h. es ist nicht nur wichtig, täglich die Daten zu sichern, sondern auch dafür zu sorgen, dass diese Sicherung wirklich nur bei Bedarf mit dem Rechner verbunden ist. Und vor der Sicherung muss man irgendwie schauen, dass man noch nicht infiziert ist (z.B. dass da nicht ungewöhnlich hohe CPU- und Disk-Aktivitäten sind, bzw. dass keine ungewöhnlich hohe Zahl von Dateien verändert worden ist. Hier noch ein recht guter (und etwas weniger detaillierter) Text zu CryptoLocker: What is it? And how do you protect against it?.

Hier ein Überblick The state of Ransomware in 2015. Und hier wiederum gibt es sehr technische Tricks zur Wiederherstellung auch ohne Backup, aber ich habe Zweifel ob das im Ernstfall wirklich funktioniert. Und es klingt nach viel Arbeit.

Hier meine Tipps:
Erst mal ist es wichtig, das Betriebssystem und die Daten zu trennen. Das Betriebssystem wenn es auf einer separaten (logischen) Festplatte ist, jederzeit (in großen Abständen) separat gesichert und bei Bedarf wiederhergestellt werden und damit kann von dieser Kopie jederzeit ein sauberes System wiederhergestellt werden.

Die Daten werden täglich gesichert, dafür ist es wichtig, dass die nicht irgendwo zwischen den Systemdateien liegen, so wie die Betriebssysteme das gern tun. Aber mit etwas Arbeit lassen sich auch die Maildateien und ähnliches auf die Datenplatte legen. Diese Sicherungsplatte muss dann während des normalen Betriebs offline sein, damit die Ransomware Software da nichts anstellen kann.

 




04.11.2013 - Mögliche Angriffe gegen Computer-Chips

Ein Wissenschaftler hat eine Technik entwickelt, wie ein Hersteller von Computer-Chips diese während der Herstellung so manipulieren kann, dass z.B. die Zufallszahlen die dieser Chip erzeugt, nicht wirklich zufällig sind, aber diese Manipulation beim Testen der Chips durch die Firma die die Chips einkauft und in ihre Produkte einbaut, nicht erkannt wird. So könnte z.B. durch Manipulation der Dotierungen einzelner Schaltkreise/"Transistoren" dafür gesorgt werden, dass bestimmt bits immer einen bestimmten Wert annehmen und daher die Zufallszahlen dann nur noch eine sog. Entropie von 32 bit statt 128 bit haben.

Das ist bisher nur eine Verschwörungstheorie, aber Bruce Schneier fällt auf: " . . . And I was always leery of Intel strongly pushing for applications to use the output of its hardware RNG directly and not putting it through some strong software PRNG like Fortuna. And now Theodore Ts'o writes this about Linux: "I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction."

Diese Idee passt eigentlich sehr gut zu den Aktivitäten der NSA zur Schwächung von Verschlüsselungsstandards, über die ich an anderer Stelle schreibe und die 50-seitige Liste von "Implants" die z.B. in Geräte von Zielpersonen oder Zielorganisationen eingebaut werden.

 




24.08.2013 - Eine unerfreuliche Public-Private Überwachungs-Partnerschaft

2 sehr bewegende Dokumente handeln von den Hintergründen der Veröffentlichungen rund um Snowden und die NSA: Ein sehr ausführlicher Artikel im Wochenend-Magazin der NYT berichtet detailliert darüber, was hinter den Kulissen bei den Snowden Veröffentlichungen abgelaufen ist: How Laura Poitras Helped Snowden Spill His Secrets und wie die Behörden ihr seit Jahren das Reisen schwer machen (inkl. einer Episode in Wien).

Der zweite Artikel beschreibt, was David Miranda, der bei der Aufdeckung der Snowden-Affäre mitgeholfen hat, auf dem Heimflug auf dem Londoner Flughafen passiert ist: David Miranda, schedule 7 and the danger that all reporters now face. "Schedule 7" bezieht sich auf den Abschnitt 7 im britischen Anti-Terrorismus-Gesetz von 2000, das hier interessanterweise zum Einsatz kommt. Ganz wichtig ist, dass Miranda im Laufe dieser Stunden in keiner Weisung irgendeiner Tat beschuldigt wurde, denn dann hätte ihm ein Anwalt zugestanden. Ohne Beschuldigung gibt es auch kein Recht auf anwaltliche Unterstützung.

Ein weiteres Beispiel zeigt die US-Organisation ACLU auf: No Warrant, No Problem: How the Government Can Get Your Digital Data. Hier geht es um die Beschlagnahmung von elektronischen Geräten an US-Grenzen ohne dass ein Verdacht begründet werden muss indem ein sog. "Travel Alert" für diese Person ausstellt. In diesem Beispielfall ging es um jemanden, der für die Verteidigung vom Manning Geld gesammelt hat.

Ein anderer Beitrag auf dieser Website diskutiert, welche Rechtlosigkeit wir alle bei Grenzübertritten haben und wie gegen Personen vorgegangen wird, die unbequem sind. Es zeigt auch, dass viele der Gesetze die angeblich gegen Terroristen gemeint sind, mindestens so aktiv gegen Unbequeme eingesetzt werden.

Primärer Anlass dieses Artikel ist (neben der PRISM-Affäre) ein Beitrag von Bruce Schneier zu diesem Thema. Sein Bild ist folgendes:

Wenn unsere Regierungen uns auffordern würden, Kopien unserer Emails bei den Behörden zu hinterlegen, mit einem Tracking Device durch die Gegend zu laufen und immer dann, wenn wir neue Kontakte machen, diese bei einer Behörde zu hinterlegen, so würden wir vermutlich heftig rebellieren.

Es hat sich aber eine für die Regierungen sehr effiziente "Public-Private Partnership" ergeben, die genau das zum Ergebnis hat. Wir (d.h. fast alle von uns) liefern alle diese Daten (und mehr) regelmäßig und freiwillig bei (US-)Firmen ab und die Regierung braucht nur höflich dort anzufragen und sie erreicht genau das, was wir eigentlich nie erlauben würden.

Ende 2013 starten die Firmen AOL, Apple, Facebook, Google, LinkedIn, Microsoft, Twitter und Yahoo eine gemeinsame Initiative bei der sie sich über die Überwachung durch die NSA aufregen: die schadet nämlich (u.a. auch) dem Geschäftsmodell.

Die Free Software Foundation weist auf die Ironie hin, dass genau diese Firmen es sind, die durch ihre Dienste einen riesigen "Daten-Sog" ins Internet erzeugen und uns dazu bringen, immer mehr Daten in die Cloud zu legen, wo diese Daten dann durch die NSA abgegriffen werden können (sofern sie nicht sowieso heimlich mehr oder weniger freiwillig hergegeben haben). Wenn es keine Social Network Dienste gäbe, so würde kaum jemand freiwillig sein Leben, seine Erlebnisse und seine Gefühle im Internet protokollieren.

Er schreibt: das primäre Business-Modell im Internet scheint mittlerweile "Überwachung" zu sein, durchgeführt durch private Firmen wie Google, Facebook, LinkedIn, Xing, Microsoft, Apple, usw., aber auch Telekom-Firmen wie Verizon, Vodafone, British Telecom, eine lange Liste. Diese leben davon, dass sie möglichst viel über uns erfahren und dieses Wissen zu Geld machen können. Daran könnte sie (abgesehen von den Konsumenten, die sich auf einen solchen Deal nicht einlassen) nur die Regierungen durch entsprechende Gesetze abhalten. Die Regierungen haben aber daran überhaupt kein Interesse, denn diese Firmen erledigen für die Regierungen (quasi kostenlos) die Sammlung und sehr aufwendige Analyse dieser Überwachungsdaten. Die Ergebnisse dieser Analysen können die Regierungen dann entweder kaufen oder aber mittels Gerichtsbeschluss beschlagnahmen. Im August 2013 stellt sich dann heraus, dass die US-Regierung die Firmen auch für die beschlagnahmten Daten bezahlt hat.

Einerseits kommt auf diese Weise die Regierung an Daten, die normalerweise "off-limit" wären und anderseits muss die Web-Industrie nicht fürchten, dass man ihre Datensammelwut durch Gesetze einbremst.

Hans Zeger von der ARGE DATEN weist unter PRISM, X-KEYSCORE UND EUROPÄISCHE EMPÖRUNGSRITUALE ebenfalls auf diese symbiotische Beziehung hin und dass die EU ja mit Begeisterung Vorratsdatensammlung betreibt und mit Programmen wie INDECT Forschungen finanziell fördert, die zu sehr ähnlichen Ergebnissen führen sollen (". . . . tools for automatic threat detection", d.h. das automatisierte Erkennen von abweichendem Verhalten, so dass die Behörden bereits einschreiten können, bevor ein Verbrechen begangen wurde, schön dargestellt im Film "Minority Report"). Zitat Zeger:

Ebenso zur Verfügung stehen ein großer Teil der WLAN-Zugangspassworte dieser Welt: Android (und bestimmt auch die iOS Smartphones) speichern die WLAN-Zugangspassworte mit denen sich Nutzer irgendwo anmelden und sichern die "in the cloud". Und wiederum sind sie mit einem National Security Letter leicht zu haben.

Ergebnis aller dieser Aktivitäten wird sein, dass "abweichendes Verhalten" in jeglicher Form stigmatisiert und durch Belästigungen durch die Behörden bestraft wird (Beispiel zeigen wie bereits heute Personen auf Grund falscher Daten oder Namensverwechselungen belästigt werden). Ergebnis ist dann langfristig eine langsame aber sichere Anpassung in Richtugn auf "unauffälliges Verhalten" und eine Ausgrenzung all derer, die da nicht mitwollen.

Ein weiterer guter Artikel kommt vom Forum Privacy der Österreichischen Computer Gesellschaft (OCG).
Zitat:

Eine andere Partnerschaft wird an anderer Stelle beschrieben: Google hat der NSA argumentatorisch den Weg bereitet indem Google seit 2004 die Emails auch von Nicht-Kunden automatisiert analysiert (so wie die NSA das auch tut) und das als "irgendwie OK" hinstellt, obwohl ja der Nicht-Gmail Nutzer nie den Nutzungsbestimmungen zugestimmt hat.

Und leider haben Google (und viele andere) nicht nur organisatorisch den Weg geebnet, sondern sogar technisch:

Im Dezember 2013 bringen Snowden-Papiere ein schönes Beispiel für eine sehr unschöne, wenn auch von Seiten der Internetanbieter ungewollte Symbiose: im Rahmen der NSA Programme QUANTUM und QUANTUMCOOKIE identifiziert die NSA ihre Opfer mittels der Cookies von Google oder Facebook, Yahoo!, Microsoft, LinkedIn, Slashdot, etc.)

Mehr zum Thema Symbiose zwischen Staat und Firmen in Privacy versus government surveillance: where network effects meet public choice:

"its was the existence of large service firms like Google, Facebook, Yahoo and Microsoft which control the personal information of many millions of people that enabled the intelligence agencies to gain cheap and convenient access via PRISM, while the relatively small number of international cable operators facilitates TEMPORA."

Zu ähnlichen Schlüssen kommt auch Peter Moeschl im Standard: Die schöne, neue Verschwörungswelt der NSA. Zitat:

In einem neureren Artikel schreibt Bruce Schneier, dass es erste Anzeichen gibt, dass sich diese Partnerschaft für die Firmen nicht mehr rechnet. Ihre Kunden sind beunruhigt (speziell Firmenkunden) und legen ihre Daten evtl. doch in keine US-Cloud: A Fraying of the Public/Private Surveillance Partnership. Und das wäre gut, denn "today's secret NSA programs become tomorrow's PhD theses, and the next day's criminal hacker tools."

 

April 2014:
Bruce Schneier hat sein Statement noch mal aktualisiert und präzisiert: The Public-Private Surveillance Partnership Is Still Going Strong. Er wehrt sich heftig dagegen, dass Google, Facebook und die Überwachungsbehörden jetzt scheinbar zurückrudern und zu vermitteln versuchen, dass jetzt alles wieder gut wird. Die Firmen verschüsseln ihre Daten besser, die US-Behörden überlassen die Datensammlung zum Teil den Firmen. Aber wenn man die Statements genau liest, so sind sie weiterhin voller Halbwahrheiten: "Die Daten werden nicht unter dem Gesetz XYZ gesammelt" oder "Wir stellen den Behörden keine Daten zur Verfügung, außer wir sind gesetzlich dazu verpflichtet". D.h. es läuft eigentlich weiter wie bisher: Die Firmen sammeln die Daten weil es ihr Geschäftsmodell ist, und die Behörden fordern die Daten an, wann immer sie sie brauchen können. Und wir Nutzer stellen ihnen bereitwilligst alle unsere Daten zur Verfügung. Standortdaten der Handys sind ein alter Hut, jetzt kommen die Armbänder die alle unsere Bewegungen und noch Gesundheitsdaten liefern.

 




27.04.2013 - Wenn Technologie nicht mehr kontrollierbar ist

Dieser Text findet sich jetzt unter dem Stichwort Der Kampf ums Internet auf einer separaten Seite.

 



Das CERT.at hat einen lesenswerten Übersichtsbericht erstellt: Special Report: Der Spamhaus/CloudFlare/Stophaus Denial of Service Angriff. Sie gehen auf die Hintergründe und die technischen Herausforderungen ein.


14.04.2013 - Hintergründe zu den dDoS-Angriffen Frühjahr 2013

In der Presse werden die Ereignisse der letzten Wochen als Spammerkrieg bezeichnet und die Meinungen schwanken zwischen "naja, ist ja nichts passiert" und "das Internet war am Rande seiner Kapazitäten".

Hintergrund ist eine Auseinandersetzung zwischen zwei eher fundamentalistisch eingestellten Organisationen: einem Web-Hoster der unter dem Namen CyberBunker bekannt wurde und Spamhaus, einer Organisation die sehr militant gegen Spammer vorgeht, bzw. gegen alles, was sie für Spammer hält oder das Spammer nicht aktiv genug bekämpft. CyberBunker ist nach eigener Einschätzung ein Verteidiger der Internet-Freiheit und hostet nach eigenen Aussagen alles außer Kinderpornographie oder Terrorismus, d.h. sie haben kein Problem Phishing-Websites oder Schadsoftware-Verteilung zu hosten - Ethical Hosting kann man das nicht gerade nennen.

Spamhaus bekämpft Spam und geht dabei recht hart vor: Sie blockieren zwar selbst überhaupt nichts, sondern liefern nur sog. Blacklists, die dann von Unternehmen für die Blockierung genutzt werden. Unproblematisch ist das Blockieren in der SBL (Spamhaus Block List) von IP-Adressen die aktiv Spam versenden. Heute wird jedoch viel Spam über Botnets versendet, für diese IP-Adressen gibt es eine Policy Block Lists mit infizierten PCs und eine Exploits Block List mit Maschinen die Spam-related Malware verteilen.

Problematischer wird es mit dem Register of Known Spam Operations (ROKSO). Hierdrin sind IP-Ranges von Organisationen drin, denen Spamhaus unterstellt, Spammer zu unterstützen. Und dann gibt es noch die DROP-Liste ("don't route or peer"). Da sollen Adressen rein von Kriminellen und alle Router-Administratoren sollen diese Adressen nicht weiter bedienen. Auf diese Weise wird ein Unternehmen quasi aus dem Internet entfernt. Das ist eine drastische Maßnahme. Mittels einer sog. Escalation versucht Spamhaus, sich durchzusetzen. Das passiert so, dass zuerst einzelne IP-Adressen blockiert werden und dann nach und nach immer weitere IP-Ranges. Wenn dies gegen ISPs (Internet Service Provider) passiert so kommen auch unbeteiligte Unternehmen zu Schaden, d.h. sie werden blockiert. Indem sie immer mehr Adressen einbeziehen erzwingen sie fast immer ein Nachgeben. Das sehen nicht nur Spammer als Erpressung.

Auch NIC.AT wurde mal auf diese Liste gesetzt weil dort 2 Domains angemeldet waren, die von Spamhaus als Spammer eingestuft waren. NIC.AT erklärte, dass sie diese Domains nach den österreichischen Gesetzen nicht entziehen können. Auf Grund dieser Antwort wurde NIC.AT als "spam support service" eingestuft und selbst blockiert. NIC.AT hat darauf hin die Domainen gelöscht - Erpressung eben.

Gegen CyberBunker, bei denen Spammer eine angenehme Heimat finden, ging Spamhaus härter vor: CyberBunker ist über den Service Provider A2B im Internet. Als in 2011 A2B CyberBunker nicht vom Netz nahm setzte Spamhaus 2048 IP-Adressen auf ihre Blacklist.

CyberBunker und andere haben dann eine Organisation STOPhaus gegründet, deren Ziel es sei, Spamhaus das Handwerk zu legen. Der Sprecher von CyberBunker (und Stophaus), Sven Olaf Kamphuis, ist eine sehr schillernde Persönlichkeit, der auch schon mal von "jüdischer Verschwörung" redet. Irgendjemand hat dann die distributed Denial of Service Angriffe (dDoS) gestartet und zwar zuerst gegen die Server von Spamhaus. Die haben sich aber Hilfe geholt, nämlich die Firma CloudFlare, die darauf spezialisiert ist, DoS-Angriffe abzuwehren (die Details finden sich in den Links).

Daraufhin eskalierte STOPhaus die Angriffe und griff nicht nur Spamhaus selbst an, sondern versuchte, ganze Internet-Exchanges lahm zu legen. Dies sind die zentralen Knotenpunkte in denen die Lichtleiter zusammenlaufen und die weltweiten Verknüpfungen hergestellt werden. Dadurch waren eine ganze Reihe von Servern nicht mehr zu erreichen. Ob die Angreifer es damit geschafft haben, das Internet ganz nahe an den Rand seiner Kapazitäten bringen oder doch nicht, das ist ein Streit zwischen Experten. Einige davon sagen, dass die Lage nicht wirklich kritisch war, aber dass CloudFlare versucht, Angst zu schüren um seine Dienste zu verkaufen. Was stimmt, kann ich nicht beurteilen, es spricht aber viel dafür, dass das Geschrei vom drohenden Untergang des Internets eher eine Werbeaktion von CloudFlare war, bei der auch die Qualitätsmedien mitgemacht haben.

Interessant sind aber die Techniken die eingesetzt wurden um diesen riesigen Datenverkehr zu erzeugen. Man nennt die Techniken Amplifikation. Das Haupttool sind 25 million open DNS resolvers, die für DNS amplification verwendet werden können. (Die NY Times stellt das sehr schön graphisch dar: How the Cyberattack on Spamhaus Unfolded). Die technischen Details sind in den Links.

Bruce Schneier weist darauf hin, dass wir es hier mit 3 Fällen von Externalitäten zu tun haben:

  1. Bots (d.h. infizierte Zombie-PCs) empfangen 1 Kommando und senden dann an DNS-Requests . . .
  2. mit falschen Absenderadressen an . . .
  3. Open DNS resolvers, die das tun was sie tun sollen, nämlich antworten und damit große Datenmengen an das Ziel (Opfer) senden.

Um das Problem zu bekämpfen müssten die Benutzer ihre infizierten PCs bereinigen, die ISPs müssten verhindern dass ihre Kunden Pakete versenden, die nicht die eigene Adresse als Absender hat und die Administratoren müssten ihre DNS-Server besser konfiguieren. Aber keiner der 3 ist direkt vom Angriff betroffen und hat einen guten Grund, hier jetzt viel Aufwand reinzustecken.

Die ICANN versucht jetzt (April 2013), Regulierungen bzgl. dem Blocken von Internet Traffic zu finden. Sie setzen dafür ein Blocking Usage Review Panel (BURP) ein. Wenn jemand dort blockiert wird und sich beschwert, so hebt dies erst mal die Blockierung auf, bis das Gremium entschieden hat.

Hier noch ein Bericht von Cert.AT zu den Vorfällen (12 Seiten Details).

 

 


Alptraum Google Glass

Die Informationen zu Google Glass und anderen intelligenten Brillen sind jetzt im Artikel zum Internet of Things




24.02.2013 - Aaron Swartz und die Anonymous Rache

Einige Hintergründe zum Fall Aaron Swartz und der Anonymous Rache (OpLastResort)

Eine recht wild Geschichte (falls das alles so stimmt). Es wird berichtet, dass Anonymous Mitglieder am 1. Februar Wochenende die US-Regierung ordentlich gepiesakt hat. Es wurden eine Reihe von Websites übernommen, auf einer wurde ein Computerspiel installiert und dann wurde auf der Website der US Sentencing Commission ein Spreadsheet mit Daten von 4600 "Bankern" veröffentlicht (contact information and cell phone numbers for U.S. bank Presidents, Vice Presidents, COO's Branch Managers, VP's and more). Anonymous gibt an dass es um eine Änderung der Gesetze geht, die Aaron Swartz zum Selbstmord gebracht haben sollen.

Jetzt zur Aaron Swartz Story. Er war ein recht bekannter Aktivist, der als seine letzte Aktion kostenflichtige MIT-Veröffentlichungen ins Internet gestellt hat. Er hat dafür kostenpflichtigen Zugang gekauft, aber dann 4 Milllionen dieser Dokument weiterveröffentlicht hat. Das war sicher eine Verletzung der Nutzungsbedingungen, aber das MIT weigerte sich, deswegen Strafantrag zu stellen.

Das FBI hat dann gegen Aaron Swartz eine Anklage wegen "wire and computer fraud" zusammengestellt und ihn mit 35 Jahren Gefängnis bedroht. Was wurde ihm vorgeworfen: Er hätte seine Identität verschleiert indem er MAC- und/oder IP-Adresse seines Laptops manipuliert hätte. Er hat sich in der Zelle umgebracht.

Anonymous fordert nun, dass das Gesetz zu "wire and computer fraud" so geändert wird, dass das Fälschen von MAC- und IP-Adressen nicht darunter fällt.

Auch noch dazu: Anonymous reveals ample Fed access, FBI opens criminal investigation.

Anonymous wehrt sich und veröffentlicht mehr Dokumente. Da gibt es auf einmal einen interessanten Zusammenhang mit dem Einbruch bei Stratfor (Strategic Forecast) ist ein US-Think Tank, bzw. ein Schatten-CIA, wie manche meinen. In den Emails die 2010 entführt wurden gibt es wohl Hinweise auf Verbindungen zwischen Stratfor und Investment-Firmen, bzw. die Idee, gemeinsam die Erkenntnisse die Stratfor bei ihrem Research gewinnt, an der Börse einzusetzen, das klingt stark nach Insider-Handel: Anonymous OpLastResort hacks investment firm, cites Stratfor ties.

 




27.01.2013 - Kann dDoS politischer Protest sein?

In den USA wird derzeit diskutiert, ob ein politisch motivierter distributed Denial of Service (dDoS) eine zulässige Protestform sein kann. Der verlinkte Artikel hat den Titel "The Right to Bear Low Orbit Ion Cannons" und spielt auf die US-Verfassung mit ihrem "right to bear arms" (das Recht, eine Waffe zu tragen) in Verbindung mit der dDoS-Tool LOIC (Low Orbit Ion Cannon - einer fiktionalen Waffe aus einem Computerspiel) an.

Interessanterweise berichtet der Artikel dann aber über die Rechtssituation in Deutschland, wo es mehrere Urteile dazu gab. Die Wikipedia berichtet über dieses Thema unter dem Titel Online-Demonstration. Die Argumentation der Beführworter ist, dass es sich um Wechseln zu: eine Online-Demonstration oder ein Virtuelles Sit-In handelt und genauso erlaubt sein sollte wie das Blockieren des Zugangs zu einem Gebäude, das in Deutschland erlaubt ist, so lange keine Gewalt angewendet wird.

Hier aus der Wikipedia zum Lufthansa-Fall, bei dem sich der Protest gegen die Abschiebung von Asylbewerbern gerichtet hat, die mit der Lufthansa ausgeflogen wurden bevor der Rechtsweg ausgeschöpft war. Dabei wurde versucht, die lufthansa.com Seite für 2 Stunden während einer Vorstandskonferenz zu fluten:

Wikipedia berichtet noch von einigen weiteren Fällen aus Deutschland und anderen Ländern. Juristisch sind die Aussichten mit dieser Argumentation durchzukommen besser als in vielen anderen Ländern, da dort im Artikel 8 der Verfassung steht,

  1. Alle Deutschen haben das Recht, sich ohne Anmeldung oder Erlaubnis friedlich und ohne Waffen zu versammeln.
  2. Für Versammlungen unter freiem Himmel kann dieses Recht durch Gesetz oder auf Grund eines Gesetzes beschränkt werden.

Juristisch zu klären ist, ob eine Online-"Versammlung" unter diesen gleichen Schutz fällt.

 



Im Rahmen der NSA-Snowden-PRISM-Affäre wurde bekannt, dass die NSA zumindest schwache Verschlüssellungen abhören kann. Daher stellt sich dann die Frage:

Wie gut ist eigentlich die Internetbanking-Website ihrer Hausbank?

Das prüft man am leichtesten mit Hilfe dieser URL: Qualys SSL Labs Server Test. Sie geben einfach den vorderen (Domain-)Teil der URL ein die Sie während der Banking-Session und/oder beim Login im Browser angezeigt bekommen. Wichtig ist nicht nur, dass dort starke Algorithmen angeboten werden, sondern auch, dass schwache Ziffern gar nicht erlaubt sind. An anderer Stelle mehr zur Stärke von Algorithmen in Post-Snowden Zeiten.

Denn ein Man-in-the-Middle Angreifer wird versuchen, den Server in Ihrem Namen zu überzeugen, dass ihr Browser nur schwache Verschlüsselungen kann. Dann sollte ihre Bank die Verbindung ablehnen. Falls die Server ihrer Bank schlecht abschneiden, dann sollten Sie diese kontaktieren.


12.01.2013 - HTTPS-Herausforderungen

Dieser Artikel behandelt die grundsätzlichen Herausforderungen, die wir derzeit im HTTPS-Ökosystem haben. Dazu gehören vor allem:

  • Falsche und unsichere Implementierung von HTTPS bei sehr vielen Websites und vor allem Smartphone Apps
  • Grundsätzliche konzeptionelle Probleme der Certification Authorities (CAs)
  • Ein anderer Artikel aus dem Jahr 2011 behandelt die zahlreichen Sicherheitsprobleme die bei Certification Authorities seit 2011 aufgetreten sind.

2014 gab es leider 2 große Schwachstellen in SSL, so dass innerhalb von wenigen Stunden eigentlich alle Webserver der Welt hätten gepatcht werden müssen - ein gigantischer Aufwand: Heartbleed und Poodle. Nur die großen Dienstanbieter schaffen so etwas in 1 Nacht, bei den Nachzüglern dauert es Monate oder gar Jahre, bis endlich sichere Versionen installiert sind.

2015 erklärt die Organisation hinter PCI-DSS SSL offiziell als nicht geeignet für die Zertifizierung, da keine sichere Implementierung mehr bereit steht.

Mittlerweile ist auf Grund der 2014 bekannt gewordenen Schwächen in einigen Verschlüsselungsalgorithmen (siehe Snowden Enthüllungen) das Konfigurieren der Verschlüsselung eines Webservers nicht mehr so einfach. Hier ein OpenSSL-Cookbook (das natürlich auch TLS unterstützt).

Ebenfalls sehr empfehlenswert sind die ENISA Hilfestellungen: ENISA guidelines on Cryptographic solutions.

Hier eine sehr ausführliche und recht technische Präsentation zu diesen Themen von einer IETF-Tagung.

Das HTTPS-Ökosystem besteht aus einer Reihe von Komponenten, von denen eine gute Anzahl erhebliche Sicherheitsprobleme hat. Das Protokoll HTTPS wird implementiert mittels den Verschlüsselungen SSL oder TLS und SSL-Zertifikaten als Komponente, die sicherstellen sollen, dass die verschlüsselten Verbindungen nur zwischen Endpunkten aufgebaut wird, die sich trusten dürfen.

Das ursprüngliche Konzept: Client- und Server-SSL-Zertifikate

In der Theorie sah das ursprünglich mal so aus, dass Client (d.h. der Webbrowser) und der Webserver beide jeweils selbst ein SSL-Zertifikat besitzen und sie das SSL-Zertifikat der anderen Stellle kennen. Dieses wird beim Verbindungsaufbau ausgetauscht und geprüft, damit wissen beide, dass sie eine direkte Verbindung miteinander haben, und dass kein böser Man-in-the-Middle dazwischen steht.

Das erste Problem ist, dass sich Client-SSL-Zertifikate nie durchgesetzt haben, weil sie für den Benutzer umständlicher wären als die jetzige Situation, d.h. die Browser werden vom Server immer akzeptiert, die Authentisierung findet über Benutzernamen und Passwort statt, mit all den damit verbundenen Passwort-Problemen. Die Server-Zertifikate werden im Browser angezeigt (durch Klick auf das Vorhängeschloss) und der Benutzer könnte jetzt z.B. beim Helpdesk anrufen und den sog. Fingerprint vergleichen. Auch dann wüsste er, dass er direkt und sicher mit dem Webserver seines gewünschten Dienstes, z.B. sein Webmail-Anbieter, verbunden ist.

Ich ignoriere jetzt mal die Schwächen der älteren Versionen der SSL- und TLS-Protokolle, die leider von den meisten Webservern weiter unterstützt werden (weil sonst die Browser nicht mehr funktionieren würden, die mehr als 5 Jahre alt sind und niemals aktualisiert wurden). Wenn die alten Protokolle vom Server noch akzeptiert werden, kann sich sehr wohl jemand in die Verbindung hängen, obwohl sie verschlüsselt ist. Begründung für das Akzeptieren der unsicheren SSL-Protokolle ist, das es immer noch Internet Explorer 6 Benutzer gibt, aber die sind fast alle in China. Das sollte für eine europäische Bank kein Grund sein, SSLv2 weiterhin zu erlauben.

Man-in-the-Middle Angriffe gegen HTTPS

Bei einem Man-in-the-Middle Angriff hängt der Angreifer im Datenverkehr und tritt gegenüber dem Webserver als Client auf und gegenüber dem Webbrowser als Webserver (so wie ein reverse-proxy). Die Herausforderung bei HTTPS-Verbindungen ist, dass der Browser überprüft, ob das Zertifakat, das der Angreifer gegenüber dem Browser präsentiert, in der Liste der vertrauenswürdigen Certification Authorities (CAs) enthalten ist. Falls ja, so gibt es keine Warnung. Falls es ein vom Angreifer selbst ausgestelltes Zertifkat ist ("self-signed"), so bekommt der Benutzer eine Warnung dass die Website unsicher wäre. An dieser Stelle brechen nach Studien ca. die Hälfte der Benutzer ab, die andere Hälfte geht trotzdem auf die Website und lässt sich damit den Datenverkehr abhören.

Typische Browser-Warnungen wenn Zertifikatsfehler auftreten, vom Benutzer sehr oft ignoriert.

Die einfachste Methode für einen Angriff gegen eine HTTPS-Verbindung ist wohl SSL-Stripping. Dabei macht sich der Angreifer, der es geschafft hat sich als Man-in-the-Middle in den Datenvekehr zu hängen, nicht die Mühe, dem Benutzer eine HTTPS-Verbindung vorzugaukeln, er leitet den Datenverkehr einfach über HTTP weiter und vertraut darauf, dass die Benutzer nicht merken, dass die URL-Zeile nicht so aussieht wie gewohnt. Ganz oft klappt das, weil die Benutzer am Inhalt der Seite keine Unterschied sehen. Dieser Angriff kann vereitelt werden, wenn die Website mittels HSTS dem Browser mitteilt, dass ihre Inhalte nie über http kommen werden, dies ist heute aber noch extrem selten. (Die technischen Details finden sich unter Man-in-the-Middle.)

Angreifer lösen die Herausforderung der Zertifikatsüberprüfung manchmal, indem sie einen CA hacken, so wie das seit 2011 immer wieder mal passiert ist. So konnte sich ein Angreifer nach einem solchen Angriff Zertifikate im Namen von Google, Microsoft und Facebook selbst ausstellen und die iranischen Regierungsbehörden waren in der Lage, den Datenverkehr von vermutlich mehr als 1 Mio. Bürgern mitzulesen, die Passworte zu speichern und auf deren Emails zuzugreifen. Mehr dazu weiter unten.

Eine weitere Angriffsmethode geht davon aus, dass bei den meisten Webseiten verschüsselte und unverschlüsselte Inhalte kombiniert werden. In diesem Fall reicht es, wenn der Angreifer in eine der unverschlüsselten Übetragungen "böse" Scripts einbaut, damit kann er zwar nicht den ganzen Datenverkehr abhören, aber evtl. die Kontrolle über den Browser übernehmen. Dieser Angriff wird als "Mixed Scripts" bezeichnet. Oft reicht es dann für den Angreifer, sich einen Session Cookie zu besorgen und schon hat er eine eigene Verbindung zum Account des Opfers, z.B. zu seinem Emails oder seiner Facebook-Seite. Website-Designer können diesen Angriff einmal dadurch verhindern, dass sie ALLE Inhalte mittels HTTPS übertragen, zum anderen müssen sie bei Cookies den Parameter "secure" setzen und damit können diese nicht in unverschlüsselten Verbindungen übertragen werden. Mehr dazu auch auf Living with HTTPS. Dort ist auch ein Link auf SSL Labs wo jede Website auf die Qualität ihrer SSL-Implementierung geprüft werden kann. Qualys, die diese Website erstellt hat, hat auch auf der RSA Conference 2012 vorgetragen: SSL and Browsers: The Pillars of Broken Security (pdf). Dieses Dokument präsentiert viele interessante Statistiken zum Zustand des Internets, die dadurch gewonnen wurden, dass die Ergebnisse von SSL Labs ausgewertet wurden. In dem Dokument wird es dann manchmal auch leicht technisch, dort wird auch erklärt, wie man einen Apache-Webserver korrekt mit SSL konfiguriert und wie die Website-Administratoren die Sicherheitsprobleme recht leicht vermeiden können.

HTTPS und Smartphone Apps

Das eigentlich neue Problem (seit 2010 oder so) sind aber die Smartphone Apps. Beim Browser am PC oder MacOS-System hat der Benutzer wenigstens noch die Möglichkeit, sich das Zertifikat des Servers anzusehen, beim Browser am Smartphone wird aus Platzgründen oft darauf verzichtet, bzw. in den Smartphone Apps gibt es die Möglichkeit überhaupt nicht. Mal abgesehen davon, dass eine sehr große Zahl von Apps ganz ohne HTTPS sensible Daten (z.B. Adressbücher) versendet, so zeigen Studien, dass 80% (oder so) der Apps die Verschlüsselung falsch implementieren. Darunter sind auch Bankenapps, Paypal, Amazon Payment Services, etc.

Hier sind Links zu Artikeln mit den Details dazu, z.B. The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software und Why Eve and Mallory Love Android: An Analysis of Android SSL (In)Security. Der erste der Artikel gibt sogar Code-Beispiele für App-Entwickler, die zeigen, wie es richtig und wie es falsch ist. Die Tipps für Entwickler finden sich auch in Your app shouldn't suffer SSL's problems.

Aber selbst wenn die App-Entwickler sich bemühen, die Daten verschlüsselt zu versenden, so machen es leider die meisten falsch. Sie prüfen entweder die Zertifikate die sie vom (angeblich korrekten) Webserver bekommen überhaupt nicht (und damit kann der Angreifer sein eigenes "self-signed" Zertifikat präsentieren und kann mitlesen) oder sie prüfen die Zertifikate, so wie die Browser das auch tun, gegen eine in den Browsern und den Smartphone "eingebaute" Liste von vertrauenswürdigen Zertifikatsausstellern (certificate authority). Und die Certificate Authorities sind eben manchmal gehackt und dann können Angreifer den Datenverkehr mitlesen. Dies war 2012 der Fall und die iranischen Regierungsbehörden waren in der Lage, den Datenverkehr von vermutlich mehr als 1 Mio. Bürgern mitzulesen, die Passworte zu speichern und auf deren Emails zuzugreifen.

Ein vernünftiger Schutz gegen gefälschte Zertifikate lässt sich dabei leicht implementieren. Die Technik wird Certificate Pinning und besteht darin, dass die App ja genau weiß, auf welche Website die Benutzer zugreifen werden und die Prüfung auf genau dieses Zertifikat kann im Quellcode der App fest eingebaut werden. Auf diese Weise wurden übrigens die Angriffe im Iran entdeckt: Google hat in den Chrome-Browser die Zertifikate der Google-Webseiten fest eingebaut und daher hat der iranische Angriff bei allen Browsern außer Chrome geklappt. Chrome-Benutzer haben das weitergemeldet und so kam der Angriff auf DigiNotar ans Licht.

Die konzeptionellen Löcher bei den Certification Authorities (CAs)

Das Problem ist, dass seit 2011 sich eine erhebliche Zahl von CAs hat hacken lassen (z.B. DigiNotar, Verisign, Comodo, GlobalSign, Trustwave - und das sind nur die, bei denen durch mehr oder weniger Zufall der Sicherheitseinbruch in der Öffentlichkeit bekannt wurde). D.h. es ist Angreifern gelungen, sich SSL-Server Zertifikate für prominente Internet-Domains wie z.B. Gmail und Facebook auszustellen. Diese falschen Google- oder Facebook-Zertifikate wurden dann u.a. dafür genutzt, sich den Internet-Traffic von Websurfern im Nahen Osten (z.B. Iran) reinzuhängen und deren Emails und Facebook-Posts mitzulesen. An anderer Stelle berichte ich ausführlich über die Krise bei den Certificate Authorities.

Eine der Kernschwächen des HTTPS-Systems ist, dass jede Certificate Authority (CA) auf der Welt Zertifikate für jede Domain ausstellen kann. Das bedeutet, dass 1 unsichere CA das gesamte System gefährdet (so wie dies ja auch praktisch der Fall war). Dazu kommt, dass mindestens 50 CAs im Besitz von Regierungen sind, d.h. dort können die jeweiligen Geheimndienste SSL-Zertifikate für jede beliebige Website bestellen und haben damit Zugriff auf den verschlüsselten Datenverkehr ihrer Bürger (den HTTPS-Datenverkehr, um präzise zu sein, die Skype-Verschlüsselung läuft anders und gilt (noch) als sicher).

Für CAs die SSL-Zertifikate verkaufen möchten ist es unumgänglich, dass ihr Root-Certificate in den Browsern inkludiert ist, damit die Benutzer wenn sie eine Website ansurfen für die eine bestimmte CA ein SSL-Zertifikat ausgestellt hat, keine Warnung bekommen. In den verschiedenen Browsern ist die Zahl unterschiedlich, sie kann aber über 650 liegen. Dazu kommt noch, dass auch weiteren CAs vertraut wird, wenn sie nämlich als Sub-CA eines dieser 650 CAs gelten. Dies bedeutet, dass wir es mit einer unüberschaubaren Zahl von CAs zu tun haben, von denen eine einzige unsicher sein muss, um das ganze System zum Einsturz zu bringen.

Da die EU auf Grund der desolaten Situation bei Certification Authorities plant, eine strengere Regulierung für CAs einzuführen haben Forscher der Universität Amsterdam ein wissenschafliches Papier erstelllt, das die grundsätzliche Problematik behandelt: Certificate Authority Collapse: Regulating Systemic Vulnerabilities in the HTTPS Value Chain (PDF, 31 Seiten). Dieses Dokument beschreibt einige technische Aspekte, aber das Hauptthema ist die Analyse der HTTPS-Ökosystems aus juristischer Sicht.

Dabei kommt aber die Analyse der bisherigen Vorfälle nicht zu kurz, speziell aus dem Fall DigiNotar leiten die Autoren eine ganze Reihe von Forderungen her. Dort sind nämlich die Schwächen sehr deutlich zu Tage getreten. Da offensichtlich desolate Zustände bei DigiNotar herrschten hat die Regierung kurzerhand die Kontrolle über die Firma übernommen (ohne dafür eine rechtliche Grundlage zu haben).

Dann wurde im Fall von DigiNotar entschieden, dass die Zertifikate, die kompromitiert worden waren und eigentlich als "ungültig" erklärt werden müssten ("Revocation") erst mal weiterhin gültig bleiben müssen, weil sonst der Zugriff zu ca. 85 000 Websites nicht mehr möglich gewesen wäre (und keine elektronische Steuererklärung in den Niederlanden). Dadurch wurde aber die Sicherheit der iranischen Bürger weiterhin gefährdet, die deswegen weiterhin keine Browser-Warnungen bekamen wenn die Regierung sich in ihre Internet-Verbindungen reinhängt.

Folgende Punkte sehen die Forscher kritisch bei dem neuen Entwurf einer Regulierung der Certification Authorities:

  1. Der Entwurf sieht als Begründung für die Regulierung, dass die Internetnutzer das Vertrauen in die Sicherheit ihrer Web-Aktivitäten nicht verlieren sollen. Dies ist leider am einfachsten dann erfüllt, wenn solche Vorfälle der Öffentlichkeit nie bekannt werden. Die Forscher schlagen vor, dass in Übereinstimmung mit der Europäischen Menschenrechtscharta eher die Sicherung der Privatsphäre und die Vertraulichkeit der Kommunikation die Priorität bei der Implementierung dieser Regeln sein sollte.
  2. Der andere große Verbesserungsvorschlag ist, dass die Forscher es für unwahrscheinlich halten, dass das ganze HTTPS-Ökosystem durch die Vorgabe einer Haftung der europäischen CAs für grobe Fahrlässigkeit (die im Fall von DigiNotar sicher gegeben war) repariert werden kann. Wie auch in diesem Artikel aufgezeigt gibt es eine mindestens ebenso große Mitschuld an der Situation bei den Betreibern der Website und den Entwicklern der Apps, wo nur wenige HTTPS korrekt implementiert haben. D.h. selbst wenn bei den CAs alles in Ordnung wäre, so wären die Websites und die Apps immer noch fast genauso unsicher.
  3. Die Forscher erwarten sich von einer europäischen Regelung eine Abwägung wie die Interessen in Bezug auf Vertraulichkeit der Kommunikation gegen die Verfügbarkeit der Websites bei Vorliegen eines Vorfalls im konkreten Fall gegeneinander abgewogen werden sollen.

 


 

Philipp Schaumann, http://sicherheitskultur.at/

Home

Copyright-Hinweis:

Das Copyright des Materials auf diesen Webseiten liegt, falls kein anderer Autor genannt wird, bei Philipp Schaumann. Creative Commons License
Diese Texte sind lizensiert unter der Create Commons Attribution-Noncommercial-Share Alike 2.0 Austria Lizenz. Natürlich gelten auch die Regeln des Fair Use und über Ausnahmen bzgl. der Lizenz kann jederzeit mit den Autoren gesprochen werden.