CERT.at - BlogDieser Feed beinhaltet den Blog von www.CERT.atAblauf einer Schwachstellen-Information durch CERT.at am Beispiel Ivanti Connect Secure VPN (CVE-2024-21887, CVE-2023-46805)CERT.at2024-01-26T07:09:05Z2024-01-25T14:25:00Z<p class="block">Am Mittwoch 10.01.24 17:48 veröffentlichte Ivanti die Information bezüglich der Schwachstellen CVE-2024-21887 und CVE-2023-46805 in ihrem Produkt Connect Secure VPN (früher Pulse Connect VPN) [1].<br /><br />Dies kam für uns zwar nicht ganz, aber doch überraschend, da wir zwar über das europäische CSIRT Netzwerk erfahren hatten, dass mit etwas zu rechnen ist, aber erst mit Donnerstag 11.01.24.<br />Es könnte damit in Verbindung stehen, dass der bekannte Sicherheitsforscher Kevin Beaumont auf Mastodon bereits Mittwoch 10.01.24 17:18 über Schwachstellen in diesem Produkt postete [2] . Diese Verhaltensweise ist, wenn auch interessant, nicht unbedingt optimal, weil sie eine koordinierte Schwachstellen-Kommunikation eher erschwert und im schlimmsten Fall dazu führt, dass Schadakteure ihre Spuren verwischen bevor Beweise gesammelt werden konnten.<br />Dies ist besonders relevant, wenn die Schwachstellen, wie in diesem Fall, bereits vor Veröffentlichung, also als 0-day, für die Kompromittierung von Geräten benutzt wurden.<br />Laut Berichten von Veloxity [3] und Mandiant [4] war dies <em>seit etwa Dezember 2023</em> für ausgewählte Ziele bereits der Fall.</p>
<p class="block">Nach der Veröffentlichung begann nun der normale Prozess für CERTs weltweit, ebenso natürlich für CERT.at ... die Verbreitung der Information über die Schwachstellen vorzubreiten beziehungsweise zu finalisieren. Die CERTs veröffentlichten und sendeten ihre Warnung aus. Unsere Warnung, die laufend aktualisiert wird, wurde Donnerstag 11.01.24 gegen Mittag ins Netz gestellt, über den freien RSS-Feed für Abonnenten zugänglich gemacht und ausgesandt [5]. Gleichzeitig wurden Besitzer im Österreichischen IP-Raum identifizierter Geräte über uns bekannte Kontakte direkt per E-Mail benachrichtigt. Letzteres kann herausfordernd sein, da bei vielen IPs ausschließlich die Kontakte der verantwortlichen Internet Service Provider (ISP) hinterlegt sind und hier die ISPs gefordert sind, die Information entsprechend weiterzuleiten, was außerhalb unseres direkten Einflussbreichs liegt. Die Zusammenarbeit mit ISPs ist sehr gut, aber man kann natürlich immer etwas verbessern.</p>
<p class="block">Nachdem ab Freitag 12.01.24 immer mehr Details zur Art und Weise der Kompromittierungen und zu den Schwachstellen bekannt wurden, konnten spezifischer Geräte ausgemacht werden, die betroffen sind oder noch nicht abgesichert wurden. CERT.at hat die Besitzer beziehungsweise bekannten Kontakte laufend über unsere automatisierte Lösung IntelMQ kontaktiert.<br />Eine Schattenseite von immer detailreicheren Informationen bezüglich Schwachstellen, ist die folgende Entwicklung von öffentlich verfügbaren Exploits, also Ausnutzungsmöglichkeiten. Im konkreten Fall wurde am Montag 15.01.24 ein Modul für eine bekannte Penetrationtesting-Lösung Metasploit veröffentlicht [6]. Dies erlaubte nun eine breite Ausnutzung der Schwachstellen.</p>
<p class="block">Nach weiterer Beobachtung der Lage beschlossen wir am Freitag 19.01.24 erneut an Betreiber von Geräten die ab Montag 15.01.24 ihre Geräte noch nicht abgesichert hatten, direkt Informationen über die Gefährdungslage auszusenden und Besitzer kompromittierter Geräte telefonisch zu kontaktieren.</p>
<p class="block">Mit Montag 22.01.24 haben wir nachgefasst und die Besitzer noch verbleibender verwundbarer Systeme direkt telefonisch kontaktiert. Dies ist natürlich mit Recherche-Aufwand verbunden und führt oft nicht direkt zu relevanten Ansprechpersonen.</p>
<p class="block">Der weiterführende Informationsverteilungs-Prozess könnte erheblich erleichtert werden, wenn Organisationen und Unternehmen vermehrt auf RFC 9116 setzen würden und die damit verbundene security.txt [7] mit relevanten Kontaktinformationen, wie die bereits lange benutzte robots.txt, auf ihren Internet-Seiten pflegen. Die in der security.txt enthaltenen Kontaktdaten würden den manuellen Rechercheaufwand für die telefonische und anderweitige direkte Kontaktaufnahmen stark verkürzen und bei breiter Anwendung potentiell eine Automatisierung erlauben.</p>
<p class="block">Wir beobachten die Lage weiter genau und sind in intensivem Austausch mit dem europäischen CSIRT Netzwerk und unseren internationalen Partnern.</p>
<p class="block">Sie hören von uns. ;)</p>
<p class="block"><strong>Timeline:</strong></p>
<p class="block">Di. 09.01. Erste Infos das etwas kommt werden bekannt<br />Mi. 10.01. Ivanti veröffentlicht Advisory einen Tag früher als geplant [11.01.] (abends) (Mastodon Leak Kevin Beaumont)<br />Mi. 10.01. Volexity veröffentlicht Blog mit Webshell Details<br />Mi. 10.01. CISA fügt Schwachstellen zu KEV hinzu<br />Do. 11.01. CERT.at veröffentlicht diesbezüglich ein Warning (mittags)<br />Do. 11.01. 15:40 CERT.at Oneshot ausgesendet (Geräte identifiziert [potentiell verwundbare]) (86 IPs)<br />Fr. 12.01. Mandiant veröffentlicht Blog mit Webshell Details <br />Mo. 15.01. Metasploit-Modul wird veröffentlicht (breitere Ausnutzuing [Coinminer, CredentialStealer])<br />Mo. 15.01. Externe Partner scannen nach noch verwundbaren Systemen (18 IPs)<br />Di. 16.01. Externe Partner scannen nach kompromittierten Systemen (Webshells) (0 IPs)<br />Di. 16.01. Volexity veröffentlich Blog zu breiter Ausnutzung der Schwachstellen<br />Di. 16.01. CERT.at Automatisierte Aussendung über IntelMQ an weiterhin verwundbare Systeme (14 IPs)<br />Do. 18.01. Kompromittierung durch externen Partner detektiert (1 IP)<br />Do. 18.01. Eskalation der Schwachstellen im europäischen CSIRT Netzwerk<br />Do. 18.01. Unbekannte Webshell (WIREFIRE-Variante) durch CSIRT Netzwerk an externe Partner gemeldet<br />Fr. 19.01. CERT.at eskaliert Schwachstellen<br />Fr. 19.01. WIREFIRE-Variante wird durch externe Partner gescannt<br />Fr. 19.01. Anfrage anderer externer Partner auf weitere Kompromittierung in Österreich (16.01. 1 IP) - bereits mitigiert<br />Fr. 19.01. Direkte telefonische Kontaktaufnahme mit Besitzer weiterhin kompromittiertem System<br />Fr. 19.01. 15:38 Oneshot (potentiell kompromittiert, noch verwundbar ab 15.01.)<br />Fr. 19.01. CERT.at Update Warning<br />Fr. 19.01. CERT.at Automatisierte Aussendung über IntelMQ an neue verwundbare Systeme (1 IP)<br />Mo. 22.01. CSIRT Netzwerk Meeting bezüglich Schwachstellen<br />Mo. 22.01. CERT.at beginnt telefonisch Besitzer von Geräten auf IPs, die ab 15.01. und noch verwundbar waren, zu kontaktieren.<br />Mo. 22.01. QUOINTELLIGENCE veröffentlich Blog-Post zu WIREFIRE-Variante<br />Mo. 22.01. CERT.at Automatisierte Aussendung über IntelMQ an neue verwundbare Systeme (2 IP)<br />Di. 23.01. Weitere Beobachtung Informations-Kanäle<br />Di. 23.01. CERT.at Automatisierte Aussendung über IntelMQ an neue verwundbare Systeme (1 IP)<br />Mi. 24.01. Keine kompromittierten Geräte in Scans von externen Partner mehr in Österreich<br />Mi. 24.01. CERT.at Warning erneut wegen negativem Einfluss eines automatischen Konfiguration-Push auf Mitigation aktualisiert<br />Do. 25.01. CERT.at finalisiert Blog-Beitrag zu diesem Thema. <br />Do. 25.01. Verwundbare Geräte im österreichischen IP-Raum noch vorhanden. (8 IPs)</p>
<hr />
<p class="block">[1] <a href="https://forums.ivanti.com/s/article/KB-CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US">https://forums.ivanti.com/s/article/KB-CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US<br /></a>[2] <a href="https://cyberplace.social/@GossiTheDog/111732557100241084">https://cyberplace.social/@GossiTheDog/111732557100241084</a><br />[3] <a href="https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/">https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/</a><br />[4] <a href="https://www.mandiant.com/resources/blog/suspected-apt-targets-ivanti-zero-day">https://www.mandiant.com/resources/blog/suspected-apt-targets-ivanti-zero-day</a><br />[5] <a href="https://cert.at/de/warnungen/2024/1/kritische-sicherheitslucken-in-ivanti-connect-secure-und-ivanti-policy-secure-aktiv-ausgenutzt">https://cert.at/de/warnungen/2024/1/kritische-sicherheitslucken-in-ivanti-connect-secure-und-ivanti-policy-secure-aktiv-ausgenutzt</a><br />[6] <a href="https://github.com/rapid7/metasploit-framework/pull/18708/commits/4060e069ed73927066b8a242e02d794f19251e9c">https://github.com/rapid7/metasploit-framework/pull/18708/commits/4060e069ed73927066b8a242e02d794f19251e9c</a><br />[7] <a href="https://securitytxt.org/">https://securitytxt.org/</a></p>CERT.at2024-01-25T14:25:00ZEs cyberwar't wieder. Oder so.CERT.at2023-10-19T17:23:40Z2023-10-19T14:36:00Z<blockquote>
<p class="block">Wichtiger Disclaimer vorweg: Die Beiträge in unserem Blog werden von Mitarbeiter:innen von CERT.at verfasst, und spiegeln deren Meinung(en) wieder, nicht "offizielle" Meinungen und Ansichten des nationalen Computernotfallsteams.</p>
<p class="block">Ich habe mir größtmögliche Mühe gegeben, mich auf vorhandene Fakten zu konzentrieren, technische Informationen in den Vordergrund zu stellen und auch sprachlich neutral zu bleiben. Dennoch kann ich nicht ausschließen, dass mir Formulierungen durchgerutscht sind, die in irgendeiner Weise politisch gefärbt sind. Wo dies der Fall ist, handelt es sich um einen Fehler des persönlichen Lektorats und keine bewusste Meinungsäusserung - nicht von mir, und insbesondere nicht von CERT.at</p>
</blockquote>
<hr />
<p class="block">Wie schon zu Beginn des Krieges in der Ukraine vor inzwischen eineinhalb Jahren, kam es auch kurz nach den Ereignissen, die am 07.10.2023 Israel erschüttert haben, relativ schnell zu Berichten über die mögliche Rolle von Cyberangriffen in diesem Konflikt.</p>
<p class="block">Neben den Beiträgen von Journalist:innen und Nachrichtenportalen wurden soziale Netzwerke geradezu überschwemmt mit Berichten über Angriffe, zu vermeintlichen Leaks sensibler Daten und zu angeblichen Kompromittierungen kritischer Infrastruktur.</p>
<p class="block">Nach mehreren Jahren in dieser Branche hebe ich - und wahrscheinlich auch die meisten Expert:innen - in solchen Situationen bei Defacements von Webseiten aller Art schon nicht einmal mehr eine Augenbraue. Auch die unzähligen, meist kurzlebigen DDoS-Angriffe sorgen (ausser bei überarbeiteten, unterbezahlten Systemadministrator:innen kleiner Unternehmen) für keine übermäßigen Schweissausbrüche mehr.</p>
<p class="block">Das war den Angreifer:innen anscheinend bewusst, also wurden Gerüchte über einen angeblichen <a href="https://x.com/Javanmardi75/status/1710633745248600220?s=20" target="_blank">Hack des israelischen Raketenabwehrsystems "Iron Dome"</a> verbreitet, aus dem dann schnell <a href="https://twitter.com/falconfeedsio/status/1710715123302547724?s=46&t=-dkNDSDHEzyAagaVN0SDgA" target="_blank">"Angriffe gegen kritische Punkte des Iron Dome"</a> wurden. Auch israelische Unternehmen wurden Opfer - unter anderem wurden <a href="https://vxtwitter.com/Team_insane_pk1/status/1710790741516001409?s=20" target="_blank">ganze Produktionsfirmen gehackt</a> - und sogar kritische Infrastruktur in Form eines Kraftwerkes wurde <a href="https://securelist.com/a-hack-in-hand-is-worth-two-in-the-bush/110794/" target="_blank">kompromittiert</a>. Zum darüberstreuen wurden israelische Energie-, Telekommunikations- und Rüstungsunternehmen dann auch noch von einem der <a href="https://thehackernews.com/2023/10/gaza-linked-cyber-threat-actor-targets.html" target="_blank">Hamas zugerechneten Bedrohungsakteur ins Visier genommen</a>.</p>
<p class="block">Im ersten Moment, vor allem vor dem Hintergrund der analogen Geschehnisse, wirkt das wie eine Menge an erschreckenden und effektiven Angriffen auf teilweise vitale Ziele einer modernen Gesellschaft. Wenn man jedoch genauer hinschaut, dann fällt die Fassade der effizienten, effektiven, und vermeintlich vor nichts Halt machenden Hacker relativ schnell in sich zusammen.</p>
<p class="block">Welche "kritischen Punkte des Iron Dome" von den Kriminellen nun tatsächlich angegriffen wurden, ließ sich nicht in Erfahrung bringen, sonderlich effektiv scheinen die Angriffe jedoch nicht gewesen zu sein. Der Hack einer Produktionsfirma stellte sich am Ende als ein Defacement der Webseite des Unternehmens hervor. Einer Webseite, deren Relevanz ich anzuzweifeln wage, nachdem sie mehr als eine Woche später immer noch mit dem "digitalen Graffiti" der Angreifer:innen verziert ist.</p>
<p class="block">Und was das angeblich durch die Täter:innen übernommene Kraftwerk betrifft, so treffen die Berichte in der Tat zu. Unter der Voraussetzung, dass man die Bedeutung des Wortes "übernehmen" so neu definiert, dass man damit die <a href="https://securelist.com/a-hack-in-hand-is-worth-two-in-the-bush/110794/" target="_blank">Wiederaufbereitung Jahre alter Leaks</a> meint.</p>
<p class="block">Der als Letztes genannte Versuch eines der Hamas zugerechneten Bedrohungsakteurs, israelische Unternehmen zu kompromittieren hat wirklich stattgefunden - zu Beginn des Jahres, wie der <a href="https://www.microsoft.com/en-us/security/security-insider/microsoft-digital-defense-report-2023" target="_blank">Bericht von Microsoft</a>, auf den sich die Autor:innen von "The Hacker News" beziehen, auch sehr deutlich sagt. Dieses meiner Meinung nach gezielte In-die-Irre-führen hinterlässt, gerade in Anbetracht der Situation, einen mehr als bitteren Beigeschmack.</p>
<p class="block">Was einer Gruppe Angreifer:innen tatsächlich gelungen ist: Eine in Israel verbreitete mobile Applikation zur Warnung vor Raketenangriffen beinhaltete eine Sicherheitslücke, die es dem Bedrohungsakteur "AnonGhost" ermöglichte, mehrere gefälschte Warnungen (inkl. vor einem vermeintlichen Nuklearschlag gegen Israel) an mehrere tausend Nutzer:innen zu verschicken. Diesen Vorfall will ich nicht verschweigen, verbuche ihn aber offen gestanden unter "ein blindes Huhn findet auch mal ein Korn". Ein statistischer Ausreisser, wenn man so will.</p>
<p class="block">All das, was ich hier gerade aufgelistet und beschrieben habe deutet für mich darauf hin, dass sich die Geschichte wiederholt. Lautstark auftretende hacktivistische Gruppierungen (oder Personen, die vorgeben eine solche zu sein), die Defacements, DDoS-Angriffe und Behauptungen über angeblich gestohlene Daten oder kompromittierte Systeme nutzen um Aufmerksamkeit zu erregen und damit einer Konfliktpartei - oder - wie im Fall der DDoS-Wellen, die auch Österreich getroffen haben - peripher mit den Konfliktparteien verbundenen Entitäten zu schaden. Ohne dabei eigentlich Einfluss auf das eigentliche Konfliktgeschehen zu haben und ohne die Angriffe länger als einige Wochen durchzuhalten.</p>
<p class="block">Der vielleicht entscheidendste Unterschied zu den Vorgängen zu Beginn des Krieges in der Ukraine ist, dass die Angriffe in weiten Teilen einseitig waren. Während Anfang 2022 sowohl russische als auch ukrainische Akteure digitale Infrastruktur der jeweils anderen Kriegspartei unter Beschuss nahmen, so war die überwältigende Mehrheit der Angriffe seit dem Überfall der Hamas gegen israelische Ziele gerichtet.</p>
<p class="block">Ein weiterer Unterschied ist auch, dass aktuell so gut wie noch keine öffentlichen Informationen über Aktivitäten staatlich unterstützter oder kontrollierter Bedrohungsakteure vorliegen. Einzig die als "Predatory Sparrow" bekannte Gruppierung (welche von manchen Journalist:innen und Sicherheitsexpert:innen als Tarnidentität für Cyberangriffe durch israelische Geheimdienste <a href="https://www.bbc.com/news/technology-62072480" target="_blank">gesehen wird</a>) hat auf Telegram die <a href="https://cyberscoop.com/predatory-sparrow-israel-gaza-cyber/" target="_blank">Wiederaufnahme ihrer Aktivitäten bekannt gegeben</a> aber keine weiteren Informationen über etwaige Angriffe veröffentlicht.</p>
<p class="block">Das heißt natürlich nicht, dass es hier keine Angriffe gibt; diese Art von Attacken wird im Regelfall durch die Angreifer:innen nicht laut in die Welt hinausposaunt. Aber wenn man bedenkt, wie schnell im Februar 2022 und teilweise auch davor und wie viel öffentlich über Angriffe von Gruppen wie Sandworm oder APT28 berichtet wurde, so bin ich geneigt davon auszugehen, dass die vergleichsweise Abwesenheit solcher Berichte zu dem aktuellen Konflikt zu mindest ein Indiz dafür ist, dass eine geringere Anzahl solcher Operationen stattfindet.</p>
<p class="block">Einige Gruppierungen (darunter Killnet und Anonymous Sudan), denen man mit einer gewissen Sicherheit zumindest die Nähe zu Staaten beziehungsweise Nachrichtendiensten nachsagen kann, haben sich zwar zu Wort gemeldet und mit der palästinensischen Seiten solidarisch gezeigt - von diesen kam jedoch in der Vergangenheit ausser DDoS und viel heißer Luft nichts, dementsprechend bin ich nicht willens, sie im Kontext staatlicher Bedrohungsakteure auch nur im Ansatz ernst zu nehmen. Falls die Webseite von CERT.at in den nächsten Tagen nicht erreichbar sein sollte, werte ich das als Erfolg. Sogar die Bösewichte der Welt lesen, was wir schreiben. Ich fühle mich geehrt.</p>
<p class="block">Trotz dieser genannten Unterschiede, eine große Gemeinsamkeit bleibt: Hauptsächlich sind die bisher bekannten Angriffe als ein Ausdruck der Solidarität zu sehen, mit so gut wie keinen relevanten Auswirkungen und ohne jeden auch nur im Ansatz bedeutsamen Beitrag zu der Situation in der "echten Welt". Letzterer wird, auf teilweise schreckliche Art und Weise, andernorts und anderweitig geleistet.</p>
<p class="block">Ich bin - wie ich in meinem letzten <a href="https://cert.at/de/blog/2023/6/cyber-ist-effektiv-explosionen-sind-effektiver" target="_blank">Beitrag</a> zu Cyberangriffen im Rahmen des Krieges in der Ukraine bereits angemerkt habe - Security Analyst, kein Militärexperte. Aber für den Moment bleibe ich bei dem Fazit, welches ich damals bereits gezogen habe: Cyberangriffe verlieren rapide an taktischer und operativer Bedeutung wenn alternative, kinetische Möglichkeiten zur Verfügung stehen. Und ich sehe aktuell keinen Grund, warum sich das in absehbarer Zeit ändern sollte.</p>
<hr />
<p class="block">Abschließend sei gesagt: Auch wenn sich aktuell keine konkrete Gefährdung für österreichische Ziele abzeichnet, verfolgen wir die Situation aufmerksam. Wir stehen in laufendem Kontakt und Austausch mit unseren internationalen CERT-/CSIRT-Kollegen und den nationalen Koordinierungsstrukturen um gegebenenfalls rechtzeitig handeln zu können.</p>
<p class="block">Unsere generelle Empfehlungen, die wir in jeder unserer Warnung aussprechen, sind auch hier anwendbar: Nutzen Sie, wo möglich, die "automatisches Update"-Features von Software, halten Sie Firewalls und sonstige Schutzmaßnahmen aktiv, und vor allem die Ohren steif. Oh, und tragen Sie bitte Sorge dafür, dass keine Management-Interfaces irgendwelcher Appliances direkt aus dem Internet erreichbar sind.</p>
<p class="block">Letzteres hat nichts mit dem aktuellen Konfliktgeschehen zu tun, das ist einfach generell eine verdammt gute Idee.</p>CERT.at2023-10-19T14:36:00ZGNOME what I'm sayin'? - GNOME libcue 0-click vulnerabilityCERT.at2023-10-13T13:23:54Z2023-10-13T12:11:00Z<p class="block">Vorab die gute Nachricht: Es gibt keinen Grund sich im Rübenkeller zu verschanzen und das Ende der Zivilisation bei 2 Dosen Bohnen mit Speck auszusitzen. Alles ist gut. Aber fangen wir am Anfang an.</p>
<h2 class="block">CVE-2023-43641</h2>
<p class="block">Die genauen technischen Details, aufbereitet von Menschen, die sich damit besser auskennen als ich, gibt es <a href="https://github.blog/2023-10-09-coordinated-disclosure-1-click-rce-on-gnome-cve-2023-43641/">hier</a>.</p>
<p class="block">Die Schwachstelle existiert in libcue, einer Bibliothek zum Parsen von cuesheets. Was sind cuesheets? Das sind Dateien (.cue), die das Track-Layout auf einer (Audio-)CD beschreiben. Was ist eine CD? Nun, sowas Ähnliches wie eine Schallplatte aber mit mehr Hexenwerk. Was ist eine Schall...ach, lassen wir das.</p>
<p class="block">GNOME indiziert Dateien für die Suche, unter anderem eben auch eventuell vorhandene cuesheets. Das geschieht automatisch wenn man Dateien in bestimmten Sub-Directories (in diesem Fall ~/Downloads) hinzufügt oder ändert. Wieso der rotbemützte Unruhestifter dazu die komplette Datei parsen muss, kann ich nicht sagen, ich bin mit der Mechanik dahinter nicht vertraut aber in der dazu verwendeten libcue Bibliothek existiert kein Check, ob beim Parsen der Track-Offsets in der Datei ein Integer-Überlauf stattfindet und der Index deswegen negativ ist. Dieser negative Index erlaubt, außerhalb des Adressbereichs des Arrays zu schreiben und wenn man dem Programm auf diese Weise Shellcode unterjubelt, können wundersame Dinge passieren - vom langweiligen Segmentation Fault bis zur RCE.</p>
<p class="block">Nun wurde ja in den Medien so einiges geschrieben, von einer <a href="https://www.securityweek.com/one-click-gnome-exploit-could-pose-serious-threat-to-linux-systems/">"ernsthaften Bedrohung"</a> war die Rede und der eingangs erwähnte Rübenkeller sah nicht gänzlich unattraktiv aus. Wie gefährlich ist der aufmüpfige Gartenzwerg aber tatsächlich?</p>
<h2 class="block">Das Bedrohungsszenario</h2>
<p class="block">Ja, die Schwachstelle ist nicht schön, vor allem da das Betriebssystem die Indizierung übernimmt und eventuell vorhandene AV-Lösungen das möglicherweise selig ignorieren. Steht uns eine Riesenwelle von Kompromittierungen bevor? Nein, ich glaube nicht und zwar aus folgenden Gründen:</p>
<ul>
<li class="block">Die Anzahl der Linux-Systeme, die libcue in einer verwundbaren Konstellation einsetzen ist vergleichsweise gering. Den größten Anteil daran haben wohl Client-Systeme. Die Server die ich bis jetzt gesehen habe sind zum allergrößten Teil headless, der Anteil mit GUI (also möglicher GNOME-Installation) vernachlässigbar.</li>
<li class="block">Client-Systeme bekommen eher mal ein Update als ein Server, der monatelang traurig in einer Ecke vor sich hinvegetiert. Viele Clients haben automatische Updates aktiviert.</li>
<li class="block">Der Großteil der Firmen die aus mehr als 2 Leuten bestehen, verwenden eine Windows-Umgebung für ihre Clients.</li>
<li class="block">Es gibt bereits Patches, die Installation dauert wenige Sekunden (weil ihr ja alle immer brav eure Updates macht und nicht 1400 packages updaten müsst, oder? <em>ODER?!</em>)</li>
</ul>
<p class="block">Wir halten fest: Die Attack-Surface ist schon mal nicht so groß, dass man den Weltuntergang heraufbeschwören müsste und ein Upgrade auf eine gefixte Version ist hinreichend trivial.</p>
<p class="block">Das heißt aber noch nicht, dass es nicht <em>möglich</em> ist, die Schwachstelle auszunutzen. Findige Nerds werden mit ziemlicher Sicherheit den PoC-Exploit aufgreifen, die Offsets (die übrigens innerhalb einer Linux-Distro konsistent bleiben) herausfinden und das Ganze in einen einsatzfähigen Exploit verwandeln. Ich habe ein wenig mit dem Testfile und Ubuntu 2023.4 experimentiert. Die Datei wird klaglos heruntergeladen, wenn man von einer unscheinbaren Website per JS darauf weiterleitet, es handelt sich also tatsächlich theoretisch um einen 0-click Exploit (allerdings müssen die Offsets in der .cue Datei zu der jeweiligen Distro passen).</p>
<p class="block">Sollte der Exploit in Zukunft wirklich weaponized werden, fällt mir als plausible Einsatzmöglichkeit auf die Schnelle eigentlich nur das Browser Exploitation Framework (BeEF) ein, da man über einen hooked Browser zumindest ein paar Infos zum Betriebssystem des unseligen Opfers erhält.</p>
<p class="block">Im Bereich Social Engineering sehe ich nicht wirklich die große Gefahr; es gibt meiner Meinung nach in dem Szenario zuviele Variablen, was den Empfänger betrifft (benutzt dieser überhaupt Linux bzw. eine verwundbare Distro, wenn ja welche, wie müssen die Offsets dafür aussehen, etc.).</p>
<p class="block">Watering-hole attacks könnte ich mir vorstellen, allerdings hielte sich der Impact da wohl in engen Grenzen. Die Website, auf der ich per XSS den Drive-By-Download einschleuse muss entsprechend unsicher sein, das Opfer muss eine verwundbare Linux-Distro verwenden, ich als Angreifer müsste den Callback zeitnah mitbekommen usw. IMHO rein opportunistisches Script-Kiddie-Stuff.</p>
<p class="block">Fazit: Alles halb so wild, einen funktionierenden Exploit würde ich definitiv in mein Arsenal aufnehmen aber hauptsächlich deswegen, weil "haben" besser ist als "brauchen". Das heißt nicht, dass man die Schwachstelle ignorieren sollte. Just patch and move on.</p>
<p class="block">Dabei ist zu beachten, eine Linux-Distro zu verwenden, die noch aktiv supported (kein EOL) ist. Ja, ich weiß, ist naheliegend aber wir wissen alle, dass das durchaus vorkommt.</p>
<p class="block">Über Packages, für die ein Upgrade verfügbar ist kann man sich auf Debian-Derivaten mit <strong><em>apticron </em></strong>per Mail informieren lassen oder diese einfach mit <strong><em>unattended-upgrades </em></strong>automatisch aktuell halten und sich auf die (proverbiale) faule Haut legen.</p>
<p class="block">Und weil Ubuntu + GNOME eine der meistverbreitetsten verwundbaren Distros ist, gibt es das Kommando zum updaten quasi als kleines Dankeschön, dass ihr euch mein Geschwurbel bis zum bitteren Ende angetan habt:</p>
<p class="block" style="padding-left: 30px;"><code>sudo apt update && sudo apt upgrade</code></p>
<p class="block">PS: Wo wir die Schwachstelle sicher sehen werden, wird in den einschlägigen CTFs sein und darauf freue ich mich schon.</p>CERT.at2023-10-13T12:11:00ZWell, this SOCKS - curl SOCKS 5 Heap Buffer Overflow (CVE-2023-38545)CERT.at2023-10-12T10:04:21Z2023-10-12T07:09:00Z<p class="block">Nachdem letzte Woche ein Advisory zu "der schlimmsten Schwachstelle in curl seit Langem" angekündigt wurde, konnten verängstigte, verschlafene und chronisch unterkoffeinierte Admins und Security-Spezialisten nach der gestrigen Veröffentlichung den Schaden begutachten. Die gute Nachricht: Die Apokalypse ist an uns vorüber gegangen. Die schlechte Nachricht: Mit dem CVSS(v2) Score lässt sich die Schwere einer Schwachstelle nicht immer ausreichend abbilden.</p>
<p class="block">Nachfolgend ein (<strong>sehr</strong>) kurzer Blick auf die Schwachstelle selbst und warum trotz eines CVSS-Scores von 7.8 kein Grund besteht, eine Notwasserung der Beinkleider zu veranlassen.</p>
<h2 class="block">Die Schwachstelle</h2>
<p class="block">Ich werde diese Sektion kurz halten, die schmutzigen technischen Details kann man <a href="https://curl.se/docs/CVE-2023-38545.html">hier</a> nachlesen. Die Schwachstelle resultiert daraus, dass libcurl unter bestimmten Voraussetzungen einen sehr langen Hostnamen anstatt der aufgelösten Adresse an eine Variable übergibt und per memcopy() den Heap-Buffer sprengt und eventuell RCE erlaubt. So weit, so ungustiös. Die Voraussetzungen dafür sind jedoch alles andere als gängige Praxis, man muss schon ein wenig Arbeit investieren um diese zu schaffen:</p>
<ul>
<li class="block"> Ein entsprechend langer Hostname muss an curl übergeben werden. Eine wirksame Input-Validation verhindert das schon mal.</li>
<li class="block">curl muss sich mit einem SOCKS 5 Proxy verbinden um den Bug zu triggern. Diese Konstellation hab ich tatsächlich in einer Produktionsumgebung noch nie gesehen. Das heißt nicht, dass es sie nicht gibt, aber sieht für mich nach wildem Flickwerk aus und ist offensichtlich auch nicht die allerbeste Idee.</li>
</ul>
<p class="block"> Ich erlaube mir an dieser Stelle, die <a href="https://isc.sans.edu/diary/rss/30304">Zusammenfassung vom SANS ISC</a> <span style="text-decoration: line-through;">abzukupfern</span> schamlos zu stehlen:</p>
<p class="block" style="padding-left: 30px;"><em>This is only a valid exploit if you take unvalidated data and create an HTTP request via a SOCKS5 proxy to a hostname created from the unvalidated data. My recommendation is to upgrade without haste.</em></p>
<h2 class="block"> Schrecken, Angst und Panik</h2>
<p class="block">Jaja, ich weiß, CVSSv2-Score 7.8 (lt. <a href="https://www.tenable.com/cve/CVE-2023-38545">Tenable</a>). An dieser Stelle möchte ich den Maintainer von curl - Daniel "Badger" Stenberg - <a href="https://github.com/curl/curl/discussions/12026#discussioncomment-7195449">zitieren</a>:</p>
<p class="block" style="padding-left: 30px;"><em>The severity level is a blunt tool. This is a HIGH severity problem but there is still going to be a large chunk of users who will not be affected by these problems.</em></p>
<p class="block">"Blunt tool" trifft es ziemlich genau. Der CVSS-Score ist nicht der Weisheit letzter Schluss, es ist ein Hilfsmittel um die Einschätzung zu erleichtern und in keinster Weise granular (oder auch nur eindeutig) genug um jede Schwachstelle ausreichend einschätzen zu können. In Wahrheit werden zwei verschiedene Personen vermutlich unterschiedliche Scores berechnen. Nachfolgend zeige ich das am Beispiel dieser Schwachstelle.</p>
<p class="block">Sehen wir uns einmal den Vektor an:</p>
<p class="block" style="padding-left: 30px;"><strong><em>AV:N/AC:L/Au:N/C:N/I:N/A:C</em></strong></p>
<ul>
<li class="block"><strong>Access Vektor: N, Network</strong> - Also kurz: über das public Internet ausnutzbar. OK.</li>
<li class="block"><strong>Access Complexity: L, Low</strong></li>
</ul>
<p class="block" style="padding-left: 30px;"><em>Specialized access conditions do not exist. [...] The affected configuration is default or ubiquituous. </em></p>
<p class="block">Nein, eher nicht. Ändern wir das mal auf <strong>M, Medium</strong> (<em>The affected configuration is non-default and is not commonly configured</em>).</p>
<ul>
<li class="block"><strong>Authentication: N, None</strong> - OK</li>
<li class="block"><strong>Confidentiality: N, None </strong>- Damit bin ich nicht einverstanden, wenn der Angriff erfolgreich ist, gehe ich aufgrund einer RCE mit zumindest User-Rechten von einem teilweisen Impact auf die Confidentiality aus. Ändern wir das auf <strong>P, Partial</strong>.</li>
<li class="block"><strong>Integrity: N, None </strong>- Hier ebenso, mit einer RCE mit User-Rechten sehe ich die Integrity zumindest teilweise kompromittiert. - Ebenfalls <strong>P, Partial.</strong></li>
<li class="block"><strong>Availability: C, Complete </strong>- Sollte der Bug ausgelöst werden, wird das curl-Kommando vermutlich abschmieren, inwiefern der darüberliegende Dienst komplett den Geist aufgeben soll, erschließt sich mir nicht. Nehmen wir in dem Fall mal eine teilweise Beeinträchtigung der Availability an - <strong>P, Partial.</strong></li>
</ul>
<p class="block">Und damit haben wir unseren neuen CVSSv2-Vektor</p>
<p class="block" style="padding-left: 30px;"><em><strong>AV:N/AC:M/Au:N/C:P/I:P/A:P</strong></em></p>
<p class="block">und einen neuen <strong>Score von 6.8</strong> und damit nur noch <strong>Medium. </strong>Sollte man das weiterspielen wollen und den Impact auf die Availability als None einstufen, landen wir bei 5.8, also im mittleren Medium-Feld. Der Definition für Access Complexity folgend, könnte man diese sogar auf High setzen, denn da heißt es:</p>
<p class="block" style="padding-left: 30px;"><em>The vulnerable configuration is seen very rarely in practice.</em></p>
<p>Und plötzlich sind wir bei einem <strong>CVSSv2-Score von 4.0</strong> und das ist gerade mal am untersten Ende von <strong>Medium.</strong></p>
<p>Abschließend möchte ich anmerken, dass Daniel Stenberg den Vorfall vorbildlich behandelt hat, durch die initiale Einstufung als High ist auch niemandem ein Schaden entstanden, eher im Gegenteil - es wurde entsprechend Aufmerksamkeit geschaffen und patchen sollte man das ja schon. Es besteht aber auch kein Grund zur Panik, es sei denn man hat wirklich ein Faible für obskure Konfigurationen, wild zusammengehackte Shell-Scripts und lebt gerne gefährlich.</p>
<p>In diesem Sinne: Gut is gangen, nix is gschehen.</p>CERT.at2023-10-12T07:09:00ZDas European Cyber ShieldCERT.at2023-09-12T11:30:59Z2023-09-12T11:20:00Z<p class="block">Die EU will im Rahmen vom "Digital Europe Programme" mit Förderungen für die Vernetzung von SOCs die Sicherheit der EU stärken und das System über einen neuen "Cyber Solidarity Act" dauerhaft einrichten.</p>
<p class="block">Ich hab dazu im Rahmen des CSIRTs Network Meetings im Juni einen Vortrag gehalten, dessen Inhalt ich jetzt auf ein ausformuliertes Paper (auf Englisch) erweitert habe.</p>
<h2 class="block">Executive Summary</h2>
<ul>
<li class="block">The proposed Cyber Shield (Chapter 2 Cyber Solidarity Act) contains valid ideas: supporting SOCs by fostering national and cross-border collaboration is worth doing.</li>
<li class="block">An unfortunate choice of terminology is prone to confuse readers of the Act. A change would be welcomed.</li>
<li class="block">The relationship between the proposed structures and the tasks of the CSIRTs and the CSIRTs network (as stipulated in the NIS2 Directive) is not entirely clear. Defining this relationship and integrating the proposed roles with the existing structures would be useful.</li>
<li class="block">EU funding for multiple consortia with the aim of building closer, technical collaborations in cross-border structures is a sound investment.</li>
</ul>
<p class="block">Das ganze Paper gibt es zum Download direkt <a class="pdf" href="https://cert.at/media/files/downloads/papers/2309/2023-09-12-european-cyber-shield.pdf">hier</a> oder über unsere <a href="https://cert.at/en/downloads/papers/">Download/Papers Seite</a>.</p>CERT.at2023-09-12T11:20:00ZPost-Quantum CryptographyCERT.at2023-09-13T10:58:25Z2023-09-07T16:04:00Z<p class="block">Das Aufkommen von fähigen Quantencomputern hat massive Seiteneffekte auf die Sicherheit diverser kryptografischer Grundoperationen. Diese sind in den letzten Jahren zu essentiellen Bausteinen unserer IT Architektur – insbesondere in vernetzten Systemen – geworden. Noch funktioniert alles, aber wenn wir nicht bald anfangen, uns auf die diese kommende Gefahr vorzubereiten, dann wird die Transition zu „post-quantum cryptography“ schmerzhafter als nötig werden.</p>
<p class="block">Konkret geht es darum, dass der Aufwand für die Operationen „Faktorisierung ganzer Zahlen“, „Diskreter Logarithmus ganzer Zahlen“ und „Diskreter Logarithmus auf elliptischen Kurven“ nicht mehr deutlich überproportional mit der Zahlengröße steigt. Damit ist die Sicherheit von RSA, ECC, DH & co nicht mehr gegeben.</p>
<p class="block">Ich darf nächste Woche bei einer <a href="https://www.qtlabs.at/stakeholder-forum/">Veranstaltung</a> dazu am Podium sitzen. Und wenn ich mich schon darauf vorbereite, dann teile ich doch gleich meine Quellen und Schlussfolgerungen. Dieser Blogpost erhebt keinen Anspruch auf Vollständigkeit.</p>
<h1 class="block">Thesen</h1>
<h2 class="block"><strong>These 1: Das Problem ist nicht neu</strong></h2>
<p class="block">Auf Sicherheitskonferenzen wird seit Jahren thematisiert, dass Quantencomputer (QC) in Verbindung mit dem Algorithmus von Schor die Eckpfeiler der aktuell verwendeten Public-Key Kryptografie aushebeln. Es wird daher schon länger nach alternativen Lösungen gesucht. Es gibt schon eine Menge Vorschläge, und auch die ersten Standardisierungen, aber es ist noch nicht ganz klar, wo der Zug hinführen wird.</p>
<h2 class="block"><strong>These 2: Es wird trotzdem überraschend kommen</strong></h2>
<p class="block">Wir Menschen sind oft sehr gut im Ignorieren von Warnungen. Klimawandel, die nächste Covid Welle, Y2K, und so weiter. „Es wird schon nicht so schlimm kommen.“ „Irgendwer wird uns schon die magische Lösung präsentieren.“ „Sollen doch mal die anderen Vorausarbeiten, ich komm dann nach, wenn alles ausgereift ist.“</p>
<p class="block">Und dann wird uns das Thema treffen wie jedes Jahr die Autofahrer der erste Schnee des Winters in Wien.</p>
<p class="block">Die <a href="https://www.youtube.com/watch?v=nSXIetP5iak">Four Stage Strategy</a> wird nicht funktionieren.</p>
<h2 class="block"><strong>These 3: Manches muss man früh angehen</strong></h2>
<p class="block">Eines der bösen Probleme bei dem Thema ist „<a href="https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later">jetzt aufzeichnen – später entschlüsseln</a>“. Wenn Daten übertragen oder gelagert werden, die langfristig geheim gehalten werden müssen, dann reicht es nicht, sich gegen aktuelle Angriffe zu schützen, man muss auch bedenken, dass ein Angreifer jetzt die Daten abfangen könnte, sie gut archiviert, und dann, wenn die Quantencomputer da sind, diese entschlüsselt. Auch bei digitalen Signaturen muss man mitdenken, was es z.B. für einen digital unterschriebenen Vertrag heißen könnte, wenn in der Zukunft der private Schlüssel einer eID errechnet werden kann, und damit alte Unterschriften gefälscht werden können.</p>
<h2 class="block">These 4: Der Umstieg wird zu lange dauern</h2>
<p class="block">Die Umstellungen, die uns durch Quantencomputer aufgezwungen sind nicht die ersten dieser Art. Immer wieder gab er Erkenntnisse, dass alte Protokolle und Algorithmen nicht mehr zeitgerecht sind. Alleine die Abkehr von MD5 als Hashing-Algorithmus in Zertifikaten war ein Drama und ich bin mir nicht ganz sicher, ob wir da wirklich schon komplett durch sind. SSL, SSLv2, TLS 1.0 und TLS 1.1 sind alle nicht mehr als sicher einzustufen. Sind wir sie los? Naja. <a href="https://www.heise.de/news/Microsoft-deaktiviert-TLS-1-0-und-1-1-in-kuenftigen-Windows-Versionen-9293694.html">Microsoft verspricht, hier bald ernst zu machen</a>. Wir haben ähnliche Ankündigungen schon oft gehört, und oft genug wird im Sinne der Rückwärtskompatibilität etwas weiterbetrieben, was schon längst auf den Misthaufen der Protokollgeschichte gehört. NTLM? SMBv1? Die Liste ist lang.</p>
<h2 class="block"><strong>These 5: Es geht nicht nur um Verschlüsselung</strong></h2>
<p class="block">Die kryptografischen Primitiven wie RSA oder ECC werden bei weitem nicht nur zum Austausch von Schlüsseln verwendet, um dann etwa mit AES einen Kommunikationskanal abzusichern. Ja, das ist auch ein Teil des TLS Handshakes, aber es wird auch überprüft, ob die Gegenstelle wirklich die ist, mit der ich sprechen will. Hier kommt die nach X.509 standardisierte Public Key Infrastruktur ins Spiel. Diese basiert auf den gleichen Algorithmen. Moderne Konzepte im Internet wie Single-Sign On, Zero Trust, Fido2/Webauthn (von Blockchain und Web 3.0 will ich besser nicht reden) bauen auch darauf auf. Aber nicht nur online ist das ein Thema: RFID in Reisepässen, <a href="https://www.paymentscardsandmobile.com/the-security-of-card-payments-in-a-post-quantum-computers-world/">Kartenzahlungen</a>, Zugangsysteme, digitale Unterschriften und die Integritätsprüfung von Software (Stichwort Secure Boot) hängen davon ab.</p>
<h2 class="block"><strong>These 6: Die Verschlüsselung ist unser kleinstes Problem</strong></h2>
<p class="block">OIDC, SAML2, SSO, JWT und wie die Techniken sonst noch abgekürzt werden: Bei Authentication und Autorisation schlagen gebrochene Schlüssel viel direkter und spürbarer durch.</p>
<h1 class="block">Empfehlungen</h1>
<h2 class="block">Informieren</h2>
<p class="block">Es gibt inzwischen von vielen Seiten wirklich gute Dokumente zu diesem Thema, etwa von den großen Sicherheitsagenturen:</p>
<ul>
<li class="block">BSI
<ul>
<li class="block">Artikel im <a href="https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Magazin/BSI-Magazin_2023_01.html">BSI Magazin 2023/01</a></li>
<li class="block"><a href="https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Broschueren/Kryptografie-quantensicher-gestalten.html">Kryptografie quantensicher gestalten</a></li>
</ul>
</li>
<li class="block">CISA
<ul>
<li class="block"><a href="https://www.cisa.gov/resources-tools/resources/quantum-readiness-migration-post-quantum-cryptography">Quantum-Readiness: Migration to Post-Quantum Cryptography</a></li>
<li class="block">Sogar einen <a href="https://www.congress.gov/bill/117th-congress/house-bill/7535/text">Gesetzesentwurf</a> gibt es schon in den Staaten</li>
</ul>
</li>
</ul>
<p class="block">Aber auch die großen Internetfirmen arbeiten schon an Lösungen und bieten sowohl Erklärungen, Software und Produkte dazu an. Etwa:</p>
<ul>
<li class="block">Google
<ul>
<li class="block"><a href="https://cloud.google.com/blog/products/identity-security/how-google-is-preparing-for-a-post-quantum-world">How Google is preparing for a post-quantum world</a></li>
<li class="block"><a href="https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html">Protecting Chrome Traffic with Hybrid Kyber KEM</a></li>
</ul>
</li>
<li class="block">DigiCert
<ul>
<li class="block"><a href="https://www.thesslstore.com/blog/post-quantum-cryptography-data-security-in-a-post-quantum-world/">Post Quantum Cryptography: Data Security in a Post-Quantum World</a></li>
<li class="block"><a href="https://www.thesslstore.com/blog/quantum-safe-encryption-digicert/">Quantum-Safe Encryption</a></li>
</ul>
</li>
<li class="block">Cloudflare
<ul>
<li class="block"><a href="https://blog.cloudflare.com/post-quantum-for-all/">Defending against future threats: Cloudflare goes post-quantum</a></li>
</ul>
</li>
<li class="block">AWS
<ul>
<li class="block"><a href="https://aws.amazon.com/de/blogs/security/round-2-post-quantum-tls-is-now-supported-in-aws-kms/">Round 2 post-quantum TLS is now supported in AWS KMS</a></li>
</ul>
</li>
<li class="block">Microsoft
<ul>
<li class="block"><a href="https://www.microsoft.com/en-us/research/project/post-quantum-cryptography/">Post-quantum Cryptography</a></li>
<li class="block"><a href="https://blogs.microsoft.com/blog/2023/05/31/building-a-quantum-safe-future/">Building a quantum-safe future</a></li>
</ul>
</li>
</ul>
<h2>Inventur machen</h2>
<p class="block">Wo hat man selber Kryptografie eingebaut? Ist man dort hinreichend agil, was die eingesetzten Algorithmen angeht?</p>
<p class="block">Welche eingekauften/installieren Lösungen nutzen Kryptografie?</p>
<p class="block">Das ist ein bisschen analog zum Y2K Problem: da war oft ein etwaiges Problem schnell gelöst, aber der wirklich große Aufwand floss in das Nachschauen, wo man betroffen sein könnte.</p>
<h2 class="block">Offenheit für neue Lösungen</h2>
<p class="block">Einfach nur die kryptografischen Primitive auszutauschen ist natürlich verlockend. Ich würde die Gelegenheit aber auch nutzen, manche Grundannahmen zu überdenken. Wo brauche ich welche Sicherheit? Habe ich eine Form von „Defense in Depth“ was meinen Einsatz von Kryptografie angeht? Treten wir uns mit dem Umstieg auf neue Algorithmen neue Angriffsflächen ein?</p>
<p class="block">Und könnte ich nicht auch die Quantentechnik defensiv nutzen?</p>CERT.at2023-09-07T16:04:00ZEin Deepdive in die ESXiArgs Ransomware KampagneCERT.at2023-08-09T23:10:43Z2023-08-09T17:07:00Z<p class="block">Es war ein schöner Tag dieser Freitag, der 03. Februar 2023, aber wie es Freitage im Cybersicherheits-Umfeld leider so an sich haben, sollte sich das schnell ändern.</p>
<p class="block">Da dieser Vorfall inzwischen schon etwas weiter in der Vergangenheit liegt, ist Ruhe um ihn eingekehrt. Allerdings gibt es doch so manch interessanten Aspekt, der - zumindest mir bekannt - so noch nicht berichtet wurde.</p>
<p class="block"><strong>Was mehr oder weniger allgemein bekannt ist …</strong></p>
<p class="block">Nach ersten Meldungen auf Twitter, dass hier etwas ganz und gar nicht Normales mit VMware ESXi Servern passiert, trafen in einem öffentlich zugänglichen Support-Forum [1] fast zeitgleich erste detailliertere Berichte über die Vorgänge von besorgten, hilfesuchenden System-Administratoren ein.</p>
<table>
<tbody>
<tr>
<td><img src="https://cert.at/media/files/news/blog/202308091715/files/Tweet1.png" width="557" height="278" /><br />Quelle: https://twitter.com/mmarcha/status/1621481244922941440</td>
<td>
<table>
<tbody>
<tr>
<td><img src="https://cert.at/media/files/news/blog/202308091715/files/Tweet2.png" alt="" width="522" height="442" /><br />Quelle: https://twitter.com/f2rv/status/1621483813523128322</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p class="block"><br />Es war kein Zugriff auf die Server mehr möglich und die Systemverwalter wurden anstatt der gewohnten Nachricht auf der Login-Seite von einem Erpresserschreiben begrüßt. Die Systeme seien verschlüsselt und nur durch Bezahlung einer nicht unerheblichen Summe in Bitcoin an die Erpresser wieder in Betrieb zu nehmen.</p>
<p class="block">Soweit nicht ungewöhnlich für solch geartete Vorfälle, auch wenn das Ausmaß der - über eine auch bis jetzt weiterhin nicht geklärte Schwachstelle (vermutet wird CVE-2021-21974 [2]) - kompromittierten Systeme noch nicht voll ersichtlich war. Da es sich bei ESXi-Servern um Virtualisierungs-Hosts handelt, auf denen teilweise zig Server- und Client-Systeme gleichzeitig laufen, konnte ein erheblicher Schaden vermutet werden.</p>
<p class="block">Eine Suche auf Censys.io ergab ungefähr 3.800 betroffene Host-Systeme [3]. Wobei hier zu bedenken ist, dass diese Zahl auf den damals auffindbaren Hosts mit öffentlicher HTTP(S)-Schnittstelle und damit erkennbarer Erpressungsmeldung basiert.</p>
<p class="block">Da die verwendete Webshell, die bereits im Dezember 2022 in einem Artikel von Juniper beschrieben wurde [4], auch Reverse-Shell-Eigenschaften (aktive Verbindung vom Host nach außen) hat, ist es möglich, dass hier weitaus mehr Systeme betroffen waren.</p>
<p class="block">Die Verschlüsselung passierte in zwei (vielleicht sogar drei und einer vierten sehr frühen - mehr dazu später) Wellen, da im ersten Anlauf bekannt wurde, dass der verwendete Verschlüsselungsalgorithmus eine Schwachstelle besitzt und somit erlaubte, auch ohne Bezahlung der Erpresser, die Daten zu entschlüsseln.</p>
<p class="block">Viele der Erpressten konnten die Webshell auf ihren Systemen nicht mehr auffinden, da das Verschlüsselungsscript diese nach erfolgreicher Ausführung gelöscht hatte, um Spuren zu verwischen. Allerdings wurde die Webshell weiter im Arbeitsspeicher ausgeführt - auch auf Systemen, wo sie durch den Administrator proaktiv gelöscht, aber kein Neustart durchgeführt beziehungsweise der Prozess nicht aktiv beendet wurde. Ein eingespielter Patch für CVE-2021-21974 [2] brachte bei bereits vorhandener Webshell ebenso keine Abhilfe, genauso wie ein Blockieren des Service Location Protocol (SLP) Ports für Zugriffe von außen. Die zweite Welle (rund um den 09. Februar 2023) mit nicht verwundbarem Verschlüsslungsmechanismus und Erpresserschreiben ohne Bitcoin-Adresse (zur schlechteren Verfolgbarkeit der Erpresser) konnte, während Administratoren bereits versuchten ihre Systeme wiederherzustellen, fast ungehindert ihren Lauf nehmen.</p>
<table style="height: 430px;" width="1086">
<tbody>
<tr style="height: 423.383px;">
<td style="height: 423.383px; width: 500.9px;"><img src="https://cert.at/media/files/news/blog/202308091715/files/ransom1.png" width="499" height="407" /><br />Info: Erpresserschreiben 03. Februar 2023 (mit Bitcoin-Adresse)</td>
<td style="height: 423.383px; width: 584.433px;">
<table style="width: 575.017px;">
<tbody>
<tr style="height: 389.883px;">
<td style="width: 581.667px; height: 389.883px;"><img src="https://cert.at/media/files/news/blog/202308091715/files/ransom2.png" width="590" height="404" /><br />Info: Erpresserschreiben 09. Februar 2023 (ohne Bitcoin-Adresse)</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<p class="block"> </p>
<p class="block">Basierend auf Daten von Shodan.io dürfte es noch eine kleinere dritte Welle um den 15. Februar gegeben haben.</p>
<p class="block">Die meisten weiteren bekannten Details sind in den Artikeln von BleepingComputer [5][6] und deren Support-Forum [1] ersichtlich.</p>
<p class="block"> </p>
<p class="block"><strong>Was nicht allgemein bekannt ist …</strong></p>
<p class="block">Wie sich zeigen sollte, war die Kompromittierung schon Monate beziehungsweise vielleicht Jahre zuvor geschehen und die ersten Opfer im Oktober 2022 (eines davon bereits im April 2021) hatten potentiell politische Relevanz.</p>
<p class="block">Es ist weiter ungeklärt, wann genau die Webshell auf Systeme eingebracht wurde, da die Akteure bedacht darauf waren, die Zeitstempel der von ihnen erzeugten Dateien zu fälschen (Timestomping) und diese nach Abschluss der Verschlüsselung zu löschen. Bei der Untersuchung eines im Februar 2023 betroffenen Hosts konnten schwache Hinweise darauf gefunden werden, dass eine Kompromittierung bereits im Juli 2022 stattgefunden hat. Dies basiert auf einer Crash-Dump Datei des betroffenen <code>rhttpproxy</code> Services, welcher benutzt wurde, um über <code>endpoints.conf</code> am betroffenen System den Zugriffspunkt für die Webshell zu konfigurieren.</p>
<p class="block">Da auf diesem Host das Verschlüsselungsscript fehlerhaft beendet wurde, blieben wertvolle Informationen erhalten.</p>
<p class="block">Der Zugriff auf die Webshell erfolgte in diesem Fall von den IP-Adressen:</p>
<ul>
<li class="block">139[.]99[.]69[.]73</li>
<li class="block">84[.]22[.]102[.]83</li>
</ul>
<p class="block"><br />Von den zehn im Oktober 2022 betroffenen Hosts konnte mittels Censys.io, Shodan.io, Zoomeye.org und passive DNS festgestellt werden, dass zumindest acht davon im betroffenen Zeitraum eine ukrainische Top-Level-Domain inne hatten und damit eine politische Motivation potentiell ableitbar ist.</p>
<p class="block"><img src="https://cert.at/media/files/news/blog/202308091715/files/shodan.png" alt="" width="1098" height="555" /><br />Quelle: <a href="https://trends.shodan.io/search?query=title%3A">https://trends.shodan.io/search?query=title%3A"How+to+Restore+Your+Files"#facet/ip</a></p>
<p class="block"> </p>
<ul>
<li class="block">51[.]83[.]141[.]52 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)</li>
<li class="block">54[.]36[.]48[.]148 - esxi04.dentsuaegis.com[.]ua - OVH SAS</li>
<li class="block">51[.]83[.]140[.]71 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)</li>
<li class="block">159[.]69[.]163[.]148 - dc2.vites.kiev[.]ua - Hetzner Online GmbH</li>
<li class="block">51[.]77[.]43[.]28 - vdc.npint.com[.]ua - OVH SAS</li>
<li class="block">51[.]83[.]237[.]4 - vdc.npint.com[.]ua - OVH SAS</li>
<li class="block">136[.]243[.]76[.]47 - sb91.binco.com[.]ua - Hetzner Online GmbH</li>
<li class="block">176[.]31[.]238[.]112 - ns342609.ip-176-31-238[.]eu - OVH SAS</li>
<li class="block">51[.]83[.]184[.]96 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)</li>
<li class="block">95[.]217[.]75[.]225 - static.225.75.217.95.clients.your-server[.]de - Hetzner Online GmbH</li>
</ul>
<p class="block"><br />Einer dieser zehn Hosts mit ukrainischer Top-Level-Domain (51[.]83[.]141[.]52) zeigte bereits im April 2021 ein entsprechendes Erpresserschreiben und wurde sogar viermal Opfer “dieser” Kampagne im April 2021, Oktober 2022, 03. Februar 2023 und 09. Februar 2023.</p>
<p class="block">Eine erste Kompromittierung im April 2021 passt auch gut zur potentiell ausgenutzten Schwachstelle CVE-2021-21974 [2], die am 23. Februar 2021 in einem Advisory durch VMware [7] beschrieben und in einem Artikel der Zero Day Initiative [8] am 02. März 2021 detailliert erklärt wurde. Auch wenn der erste Proof-of-Concept Exploit [9] erst am 24. Mai veröffentlicht wurde.</p>
<p class="block"><strong><br />Ableitbare Maßnahmen …</strong></p>
<ul>
<li class="block">Schnelles Patchen alleine reicht nicht. Eine weiterführende Untersuchung der Systeme ist gegebenenfalls notwendig.</li>
<li class="block">Management-Schnittstellen haben im öffentlichen Internet nichts verloren. Diese sollten ausschließlich über VPN oder ähnliche Lösungen erreichbar sein.</li>
<li class="block">Eingesetzte Endpoint Detection and Response (EDR) Lösungen sollten auch “Nischenprodukte” abdecken können.</li>
<li class="block">Aktives Suchen - “Hunting” - nach Unregelmäßigkeiten in allen im Unternehmen verwendeten Technologien.</li>
</ul>
<p> </p>
<hr />
<p>[1] <a href="https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/">https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/<br /></a>[2] <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-21974">https://nvd.nist.gov/vuln/detail/CVE-2021-21974 </a><br />[3] <a href="https://gist.github.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19">https://gist.github.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19 </a><br />[4] <a href="https://blogs.juniper.net/en-us/threat-research/a-custom-python-backdoor-for-vmware-esxi-servers">https://blogs.juniper.net/en-us/threat-research/a-custom-python-backdoor-for-vmware-esxi-servers </a><br />[5] <a href="https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/">https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/ </a><br />[6] <a href="https://www.bleepingcomputer.com/news/security/new-esxiargs-ransomware-version-prevents-vmware-esxi-recovery/">https://www.bleepingcomputer.com/news/security/new-esxiargs-ransomware-version-prevents-vmware-esxi-recovery/ </a><br />[7] <a href="https://www.vmware.com/security/advisories/VMSA-2021-0002.html">https://www.vmware.com/security/advisories/VMSA-2021-0002.html </a><br />[8] <a href="https://www.zerodayinitiative.com/blog/2021/3/1/cve-2020-3992-amp-cve-2021-21974-pre-auth-remote-code-execution-in-vmware-esxi">https://www.zerodayinitiative.com/blog/2021/3/1/cve-2020-3992-amp-cve-2021-21974-pre-auth-remote-code-execution-in-vmware-esxi </a><br />[9] <a href="https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9">https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9</a></p>
<p> </p>
<p class="block">Eine Attribuierung zu bekannten Gruppen oder staatlichen Akteuren ist mit den vorhandenen Indicator of Compromise (IOCs) und Tacticts, Techniques und Procedure (TTPs) nicht durchführbar und liegt auch nicht im Interesse und direktem Aufgabenbereich von CERT.at.</p>CERT.at2023-08-09T17:07:00ZCyber ist effektiv, Explosionen sind effektiverCERT.at2023-06-29T09:03:53Z2023-06-28T18:22:00Z<p class="block">Die Veröffentlichung von Dokumenten, welche vermeintlich die Arbeit eines russischen IT-Unternehmens im Auftrag russischer Nachrichtendienste beschreiben, hat durch verschiedene journalistische Publikationen Ende März dieses Jahres für einiges an Aufsehen gesorgt.</p>
<p class="block">Die "Vulkan Leaks" beinhalteten unter anderem auch Informationen zu einem Projekt, welches unter dem Namen "Kristal-2V" geführt wurde. In den Dokumenten zu eben jenem fanden sich massenhaft Verweise zu Angriffen gegen OT-Systeme und die effektive Durchführung von Informationsoperationen unter Einbeziehung dieser Angriffe.</p>
<p class="block">Was aber gerade in der initialen Berichterstattung, aus welchen Gründen auch immer, oft nicht erwähnt wurde: Es handelt sich bei Kristal-2V um eine, soweit es sich beurteilen ließ, reine Trainingsplattform. Ja, die Plattform erlaubte sowohl defensive als auch offensive Simulationen und ja, es ist davon auszugehen, dass russische Nachrichtendienste Interesse daran haben Kapazitäten zu besitzen, die zuverlässig physische Zerstörung durch Cyberangriffe ermöglichen.</p>
<p class="block">Das sind aber allesamt keine überraschenden, unerwarteten Details. Der Angriff von "<a href="https://en.wikipedia.org/wiki/BlackEnergy" target="_blank">BlackEnergy</a>" auf die Stromversorgung in der Ukraine liegt nahezu ein Jahrzehnt in der Vergangenheit, der zerstörerische Einsatz von Stuxnet in den Anreicherungsanlagen von Natanz und Bushehr noch länger - und der "<a href="https://en.wikipedia.org/wiki/Aurora_Generator_Test" target="_blank">Aurora Generator Test</a>" hat inzwischen fast schon die Volljährigkeit erreicht.</p>
<p class="block">Dennoch, diese Revelationen haben dafür gesorgt, dass das Thema Cyberangriffe mit physischen Auswirkungen auch abseits der Vulkan Leaks wieder vermehrt in's Rampenlicht gezogen wurden.</p>
<p class="block">Insbesondere die Überschriften und Schlagzeilen rund um einen potentiell möglichen, in ganz Europa geführten Cyberkrieg mit katastrophalen Auswirkungen auf die Stabilität, im metaphorischen und wortwörtlichen Sinn, unserer Gesellschaft entbehrten in Anbetracht der gegenwärtigen sicherheitspolitischen Lage in Europa nicht einer gewissen Ironie.</p>
<p class="block">Seit Februar 2022, der Beginn der russischen Invasion der Ukraine, sind wir hierzulande Zeuge eines "klassischen" Krieges, eines konventionellen militärischen Konfliktes zwischen zwei Nationalstaaten - dem ersten dieser Art seit dem Ende des zweiten Weltkrieges vor fast 80 Jahren.</p>
<p class="block">Dies bedeutet auch, dass wir zum ersten Mal einen Krieg erleben, bei dem die involvierten Parteien nicht komplett asymmetrisch sind, wie es beispielsweise im syrischen Bürgerkrieg der Fall war. Und dementsprechend wäre dies auch der erste Krieg, bei dem destruktive Cyberangriffe Teil der kombinierten Kriegsführung hätte sein können (einzelne Vorfälle in der Vergangenheit, wie beispielsweise die israelische "<a href="https://en.wikipedia.org/wiki/Operation_Outside_the_Box" target="_blank">Operation Outside the Box</a>", ignoriere ich ob des limitierten Maßstabes unauffällig). Insbesondere vor den russischen Kapazitäten in diesem Bereich wurde insbesondere in den Monaten vor Beginn des Krieges immer wieder gewarnt. Wodurch sich für mich an einem Punkt im Kriegsverlauf die Frage ergeben hat: Was ist eigentlich an diesen Befürchtungen dran gewesen?</p>
<p class="block">Um diese Frage zu beantworten habe ich versucht, in spärlichen Mengen verfügbaren öffentlichen Informationen zusammen zu tragen und herauszufinden ob, und wenn ja in welchem Ausmaß, destruktive Cyberangriffe durch russische Bedrohungsakteure direkten Einfluss auf das Kampfgeschehen in der Ukraine genommen haben - und in welchem Verhältnis deren Effektivität im Vergleich zu kinetischen Angriffen steht.</p>
<p class="block">Einige kleine, aber wichtige Details vorweg: Ich habe mir nahezu ausschließlich Daten und Informationen zu destruktiven Angriffen angesehen; Angriffe, deren Ziel die Gewinnung von Informationen war wurden weitestgehend außen vor gelassen.</p>
<p class="block">All das war ein rein empirisches Unterfangen. Auch wenn ich mich um Objektivität und Sachlichkeit bemüht habe, wissenschaftlichen Standards wurde an keiner Stelle genüge getan. Die Datenlage, was öffentliche Quellen betrifft, ist höchst dürftig und es ist nicht auszuschließen, dass in den nächsten Wochen, Monaten und Jahren Details an's Licht kommen, die meine Schlussfolgerungen vollumfänglich widerlegen. Oder, um es in den Worten eines Piraten zu sagen: Ye be warned!</p>
<hr />
<p class="block">Bevor ich in weiter ausführe, die wichtigsten Eckpunkte vorweg zusammengefasst:</p>
<ul>
<li class="block">Betrachtet man den gesamten bisherigen Konfliktverlauf, so waren destruktive Cyberangriffe aus militärischer Sicht nahezu vollständig wirkungslos, und auch in Hinblick auf Schäden an ziviler Infrastruktur nutzlos. Die Lahmlegung von VIASAT zu Beginn des Konfliktes hatte unter Umständen einen positiven Einfluss auf russische Militäroperationen, auch das lässt sich aber in keinster Weise belegen.</li>
<li class="block">Insbesondere im direkten Vergleich zu "klassischen" kinetischen Angriffen war der Schaden, welcher durch Cyberangriffe angerichtet wurde, vernachlässigbar.</li>
<li class="block">Ähnlich der initialen russischen militärischen Taktik, welche von massiven Defiziten in der Koordination zwischen den verschiedenen Truppenteilen geplagt war, wurden Cyberangriffe in den meisten Fällen sehr "stumpfsinning" eingesetzt; keine der spezifischen Vorteile von Cyberangriffen wurden genutzt.</li>
</ul>
<h2 class="block">Militärische Sicht</h2>
<p class="block">Die massenhafte Zerstörung von Modems des Unternehmens Viasat, welches einen temporären, vollständigen Ausfall des dem Unternehmen gehörenden Kommunikationsnetzwerkes KA-SAT zur Folge hatte, wurde medial als der "digitale Startschuss" der russischen Invasion gehandelt. Ersten Meldungen zu Folge hatten diese Angriffe massiven Einfluss auf die Fähigkeit der ukrainischen Streitkräfte, Verteidigungshandlungen effektiv zu koordinieren.</p>
<p class="block">Dies wurde jedoch mehrfach von ukrainischen Kommandeuren, die zu Beginn des Überfalls rund um die ukrainische Hauptstadt Kyiv im Einsatz waren, <a href="https://www.washingtonpost.com/national-security/interactive/2022/kyiv-battle-ukraine-survival/" target="_blank">bestritten</a>. Laut deren Aussagen waren die Auswirkungen des Ausfalles von KA-SAT vernachlässigbar, da eine Verwendung selbst bei voller Funktionsfähigkeit des Netzwerkes nicht möglich gewesen wäre. Sämtliche elektronische Kommunikation wurde durch Mittel der elektronischen Kriegsführung von Einheiten der russischen Streitkräfte gestört.</p>
<p class="block">Welcher Faktor nun tatsächlich ausschlaggebend für initiale Kommunikationsprobleme der ukrainischen Streitkräfte war, wurde in den von mir gesichteten Artikeln und Meinungen intensiv debattiert. Auch zwei andere ukrainische Internet Service Provider, <a href="https://www.capacitymedia.com/article/29wch971qqy0z3dyifx8g/ukrtelecom-restores-85-of-services-after-powerful-cyberattack" target="_blank">Ukrtelecom</a> und <a href="https://www.forbes.com/sites/thomasbrewster/2022/03/10/cyberattack-on-major-ukraine-internet-provider-causes-major-outages/" target="_blank">Triolan</a> wurden relativ knapp nach Kriegsbeginn Opfer von Cyberangriffen, die zu zeitweisen Problemen bei der Verfügbarkeit führten - jedoch nach Aussage ukrainischer Regierungsvertreter sowie den betroffenen Unternehmen selbst zu keiner Zeit militärische Auswirkungen hatten.</p>
<p class="block">Auch wenn keinerlei Beweise dafür vorgelegt wurden, so decken sich die Aussagen mit anderen Berichten zu Erfahrungen von ukrainischen Einheiten zu Beginn des Krieges. In den meisten davon werden (oft erfolgreiche) Versuche der funkelektronischen Störung durch entsprechende russische Einheiten (zu welchen es eine ausgezeichnete <a href="https://spectrum.ieee.org/the-fall-and-rise-of-russian-electronic-warfare" target="_blank">Analyse durch das Institute of Electrical and Electronic Engineers</a> gibt) beschrieben. Probleme, denen ein Ausfall der Service Provider zugrunde liegt, werden an keiner Stelle erwähnt.</p>
<p class="block">Auch was den militärischen Nachschub betrifft, sowohl auf operativer, taktischer Ebene als auch in Bezug auf die Zuführung von Militärhilfe durch westliche Länder, gibt es keine öffentlich verfügbaren Informationen darüber (oder auch nur Hinweise darauf), dass dieser von Cyberangriffen beeinträchtigt wurde.</p>
<p class="block">Während behördliche und zivile Einrichtungen zu Beginn des Krieges massiv durch den Einsatz von Wipern getroffen wurden (dazu später mehr), scheinen militärische Systeme weitestgehend verschont geblieben zu sein. Selbiges gilt für den direkten Verlust von Material und Menschenleben, welcher durch die Aktivitäten russischer Bedrohungsakteure ausgelöst wurde.</p>
<p class="block">Der einzige mir bekannte Fall, bei dem ein russischer Cyberangriff im Krieg in der Ukraine zu direkten militärischen Verlusten geführt haben könnte ist die angebliche Kompromittierung einer ukrainischen App zur Kalibration von älteren Haubitzen durch APT28, welcher dem russischen Militärgeheimdienst GRU zugerechnet wird.</p>
<p class="block">Das Sicherheitsunternehmen Crowdstrike beschreibt in einem im <a href="https://www.crowdstrike.com/blog/danger-close-fancy-bear-tracking-ukrainian-field-artillery-units/" target="_blank">Dezember 2016 veröffentlichten Bericht</a>, wie der Bedrohungsakteur die Endgeräte des Entwicklers der App kompromittiert hatte, um dann den Quellcode der App selbst zu modifizieren, um so Standortinformationen sammeln zu können, die in weiterer Folge für den gezielten Beschuss ukrainischer Artilleriestellungen genutzt werden konnten. Laut dem Unternehmen führte dieser Cyberangriff in weiterer Folge zu signifikanten Verlusten auf Seiten der Ukraine - bis zu 80% besagter Haubitzen.</p>
<p class="block">Ich verwende hier deswegen den Konjunktiv, weil Crowdstrike in seiner Analyse und Attribuierung zwar sehr überzeugt aufgetreten ist, allerdings sowohl der <a href="https://www.rferl.org/a/ukraine-russia-fancy-bear-hacking-artillery-guidance-app/28831564.html" target="_blank">angeblich betroffene Entwickler</a> als auch das <a href="https://cert.at/(http:/www.mil.gov.ua/news/2017/01/06/informacziya-po-vtrati-u-zs-ukraini-80-gaubicz-d-30%E2%80%9D-ne-vidpovidae-dijsnosti/" target="_blank">ukrainische Verteidigungsministerium</a> den Bericht in Frage stellen.</p>
<p class="block">Aber selbst, wenn wir davon ausgehen, dass der Bericht korrekt ist und der erfolgreiche Angriff katastrophale Folgen hatte, so handelt es sich um einen einzelnen Angriff, welcher 2016, also vor Beginn der offenen russischen Invasion im Februar letzten Jahres erfolgt ist.</p>
<p class="block">Dem gegenüber stehen tausende Verluste auf Seiten der ukrainischen Streitkräfte (und der ukrainischen Zivilbevölkerung) welche durch den Einsatz konventioneller Waffen verursacht wurde. Auch wenn die genauen Zahlen nicht bekannt sind, und aktuell nur <a href="https://en.wikipedia.org/wiki/Casualties_of_the_Russo-Ukrainian_War" target="_blank">ungefähre Schätzungen</a> vorliegen, so ist das Verhältnis mehr als eindeutig.</p>
<h3 class="block">Zivile Sicht</h3>
<p class="block">Crowdstrike bezeichnete das Jahr 2022 <a href="https://www.crowdstrike.com/blog/the-anatomy-of-wiper-malware-part-1/" target="_blank">in einem Bericht</a> als "das bisher aktivste Jahr für Wiper". Ukrainische Netzwerke, sowohl von behördlichen Stellen als auch Institutionen der Zivilgesellschaft und kommerzieller Unternehmen, wurden bis zum Sommer letzten Jahres von insgesamt fast 50 unterschiedlichen Wipern heimgesucht (die genaue Zahl schwankt, eine <a href="https://www.csis.org/analysis/hidden-war-ukraine" target="_blank">Analyse des Center for Strategic & International Studies</a> gibt mit 37 die niedrigste Zahl an, auf die ich im Zuge meiner Recherche gestoßen bin).</p>
<p class="block">Wie schon bei dem Angriff gegen VIASAT scheiden sich hier die Geister, wie hoch der effektive Schaden dieser Angriffe tatsächlich war. Während dieser von <a href="https://www.politico.com/news/magazine/2022/07/14/russia-cyberattacks-ukraine-cybersecurity-00045486" target="_blank">ukrainischer Seite als "nicht vorhanden" bezeichnet wurde</a>, spricht Microsoft von einer "<a href="https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4Vwwd" target="_blank">permanenten Zerstörung von Daten auf hunderten von Systemen von Dutzenden Organisationen in der gesamten Ukraine</a>" - nennt die tatsächlichen Auswirkungen auf die Verfügbarkeit von Services aber "limitiert".</p>
<p class="block">Selbst wenn die Auswirkungen dieser Angriffe in Wirklichkeit stärker waren als von Microsoft angenommen, sie waren nur von sehr kurzer Dauer. Wie in einer <a href="https://images.carnegieendowment.org/images/article_images/Bateman_Cyber_Fig_1_v3-01.png" target="_blank">Grafik des CyperPeace Institute</a> ersichtlich erreichte die Zahl der angegriffenen ukrainischen Systeme und Netzwerke ungefähr vier Wochen nach dem Beginn der Invasion ihren Höhepunkt; danach flachte die Kurve rasant und nachhaltig ab.</p>
<p class="block">Zwar dauert der Krieg nun bereits deutlich länger als die in der Grafik als Endpunkt verwendete Woche 35 des Jahres 2022, aber wenn man davon ausgeht, dass die in Artikeln und Beiträgen auf sozialen Medien geteilten Informationen ein halbwegs akkurates Bild russischer Cyberangriffe in der Ukraine darstellen, dann hat sich seit letztem Jahr nichts grundlegendes geändert - selbst für das wohl "interessanteste" Ziel für Angreifer:innen.</p>
<hr />
<p class="block">Das ukrainische Stromnetz war in den Vergangenen Jahren immer wieder Ziel von Cyberangriffen, die weltweit für Aufmerksamkeit gesorgt haben. Beispielhaft seien hier stundenlange, durch Schadsoftware ausgelöste Stromausfälle im <a href="https://cert.at/(https:/en.wikipedia.org/wiki/2015_Ukraine_power_grid_hack" target="_blank">Dezember 2015</a> genannt. Vor Beginn des Krieges sind viele Expert:innen davon ausgegangen, dass diese Art von destruktiven Angriffen eine wichtige Rolle im Fall einer russischen Invasion spielen würden.</p>
<p class="block">Auch in unseren Analysen als CERT sind wir davon ausgegangen, dass es diese Angriffe geben würde. Auch wenn wir versucht haben, den allgemeinen Überblick über mögliche Auswirkungen eines russischen Angriffes auf die Ukraine zu berücksichtigen hat uns die Frage, ob es im Fall solcher Cyberangriffe potentiell Kollateralschäden für österreichische Energieunternehmen geben könnte, besonders beschäftigt. Diese Fragen und Bedenken haben auch andere CERTs beschäftigt.</p>
<p class="block">Um so überraschter waren wir, als es zu Beginn des Überfalls nicht zu sofortigen, massiven, und vor allem effektiven Angriffen gegen die ukrainische Stromversorgung kam. Dies hat sich bis heute nicht geändert, öffentlich bekannt wurden seit Februar 2022 nur <a href="https://www.reuters.com/world/europe/russian-hackers-tried-sabotage-ukrainian-power-grid-officials-researchers-2022-04-12" target="_blank">zwei erfolglos gebliebene Angriffsversuche</a>.</p>
<p class="block">Dem gegenüber stehen, vor allem in den Wintermonaten am Ende des Jahres 2022, periodische Stromausfälle, die teilweise das ganze Land betrafen. Ausgelöst durch gezielte Luft-, Drohnen- und Raketenangriffe gegen alle Teile des ukrainischen Stromnetzes waren [<a href="https://www.cnn.com/2022/11/04/europe/ukraine-energy-terrorism-zelensky-russia-intl" target="_blank">zeitweise hunderttausende Menschen für mehrere Tage ohne Strom</a>].</p>
<p class="block">Zeitgleich neben den beschriebenen koordinierten Angriffen, und auch nach deren Abflauen, gab es ebenfalls immer wieder einzelne Defacements und kleinere Datenleaks, sowie konzertierte DDoS-Angriffe von vorgeblich pro-russischen Hacktivisten (wer in den letzten Monaten einmal Nachrichten mit Bezug auf IT-Security gelesen hat wird den Namen "<a href="https://en.wikipedia.org/wiki/Killnet" target="_blank">Killnet</a>" zumindest einmal gehört haben). Um die Wirkung in den (aus dem Kontext gerissenen) Worten eines Mitarbeiters des BMLV zu beschreiben: "Die Javelin hat sicher Angst, weil die Webseite der Regionalbank Kherson offline ist.".</p>
<hr />
<p class="block">Wie auch schon bei der Betrachtung aus militärischer Sicht zeichnet sich hier ein sehr deutliches Bild - der durch kinetische Angriffe angerichtete Schaden, und das damit einhergehende Leid für die Zivilbevölkerung, ist um ein vielfaches höher als der durch Cyberangriffe verursachte Schaden und die dadurch entstehenden Auswirkungen.</p>
<p class="block">Einige wenige, begrenzte Ausfälle der nationalen Konnektivität durch die Aktivitäten russischer Bedrohungsakteure sind nicht einmal im Ansatz gleichzusetzen mit den massiven Ausfällen die durch zerstörte Netzwerkinfrastruktur verursacht wurde, oder der intensiven Bombardierungen der kritischen Infrastruktur (insbesondere der Stromversorgung) des Landes - welche mit fortschreitender Dauer des Krieges militärisch kaum mehr zu rechtfertigen waren.</p>
<p class="block">Bis auf eine handvoll von zeitlich und örtlich sehr spezifischen Ausnahmen, mehrheitlich zu Beginn der Invasion, sind zerstörerische Angriffe russischer Akteure aller Couleur in ihrer Wirkung weit hinter den Erwartungen (und theoretischen Möglichkeiten) zurückgeblieben & können nach aktuellem Stand in ihrer Gesamtheit als gescheitert betrachtet werden.</p>
<p class="block">Ich bin glücklicherweise in der Position für eine Organisation zu arbeiten, die sich mit der fachlichen Analyse dieser Angriffe auf technischer Ebene beschäftigt. Detaillierte militärische Einschätzungen sowie eine Abschätzung, was die Geschehnisse im "militärischen Cyberraum" für verteidigungspolitische Entwicklungen der nächsten Jahre bedeutet liegen nicht in meiner Verantwortung (und sind auf Basis einer solchen rudimentären Analyse wie der obigen wahrscheinlich auch nicht seriös möglich).</p>
<p class="block">Dennoch möchte ich kurz einen Blick darauf werfen, was die Gründe für dieses scheinbare Versagen, beziehungsweise die Nichtigkeit dieser Cyberangriffe im "großen Ganzen", sein könnte.</p>
<h3 class="block">Was ist der Grund dafür?</h3>
<p class="block">Die Liste an Gründen für das vergleichsweise Fehlen von Erfolg, oder zumindest Effektivität, ist wahrscheinlich lange und komplex. Einige besondere Faktoren sind meines Erachtens nach herausstechend.</p>
<p class="block">Russische Bedrohungsakteure sind seit mehr als einem Jahrzehnt in der öffentlichen Berichterstattung zu Cyberangriffen präsent, und haben diese mehr als einmal dominiert. Das könnte unter Umständen fälschlicherweise den Eindruck erwecken, dass russische Nachrichtendienste über ein riesiges Heer aus bestens ausgebildeten Spezialisten verfügen, welches sich beliebig vergrössern lässt und das nur darauf wartet, auf den digitalen Feind losgelassen zu werden.</p>
<p class="block">Es gibt keine öffentlichen Zahlen zu den personellen Kapazitäten, aber es ist wohl keine gänzlich absurde Schätzung wenn man (unter Einbeziehung von russischen Staatsbürgern, die in kriminelle Aktivitäten digitaler Natur verwickelt sind und ihre Expertise aus patriotischem Enthusiasmus, der nichts mit mehr oder weniger subtil angedrohten Zwangsmassnahmen zu tun hat, zur Verfügung stellen) von einer geringen vierstelligen Zahl an zumindest grundlegend für offensive Operationen geeigneten Personen ausgeht.</p>
<p class="block">Das ist nicht unbedingt viel, insbesondere wenn man bedenkt, dass trotz der Wichtigkeit des Krieges die Ukraine nicht der einzige Schauplatz für Aktivitäten russischer Bedrohungsakteure ist.</p>
<p class="block">Und genau diese personelle Limitierung ist eines der Probleme, die die Effektivität russischer Cyberangriffe im Rahmen der Unterstützung militärischer Angriffe gemindert haben beziehungsweise dazu beigetragen haben, dass der Fokus weniger auf destruktiven Angriffen liegt, als vor Beginn des Krieges angenommen wurde.</p>
<p class="block">Als Beispiel: Um eine handvoll Kraftwerke physisch einzunehmen benötigt es (rein vom personellen Aufwand her, etwaigen Widerstand außen vor gelassen) einige geschulte Unteroffiziere und zwei oder drei Kompanien Infanteristen, deren Ausbildung zur Befolgung von Befehlen ausreicht.</p>
<p class="block">(Falls jemand mit militärischer Ausbildung sich gerade an den Kopf greift und ob meiner Milchmädchenrechnung verzweifelt, ich bitte um Nachsicht um der Argumentation willen. Bei mir hat es nicht einmal für den Zivildienst gereicht.)</p>
<p class="block">Um dieselbe Anzahl an Kraftwerken erfolgreich zu kompromittieren und die Stromversorgung negativ zu beeinträchtigen braucht es, sofern dies zeitnah geschehen soll, eine Gruppe ausgebildeter und erfahrenes Fachpersonal.</p>
<p class="block">Davon gibt es eine schnell enden wollende Menge, und diese Menge zu erhöhen ist auch nicht trivial möglich. Insbesondere dann, wenn der Pool an potentiellen Kandidaten aufgrund des durch den Krieg ausgelösten Abfluss von jungen, gebildeten Menschen stetig schrumpft. Ohne Einblick in die Kapazitäten anderer Staaten zu haben gehe ich davon aus, dass dieses Problem auf die meisten staatlichen Bedrohungsakteure zutrifft. Cyberangriffe skalieren nur sehr limitiert.</p>
<p class="block">Weiters waren russische Bedrohungsakteure über weite Teile nicht in der Lage, die typischen Vorteile von Cyberangriffen auszunutzen. Oder, um es etwas besser auszudrücken: Russland hatte es nicht notwendig, diese auszunutzen.</p>
<p class="block">Wenn man bereits dabei ist, in ein Land einzumarschieren, dann sind Dinge wie Kosteneffektivität, glaubhafte Bestreitbarkeit und die Möglichkeit, Kollateralschäden zu vermeiden nicht mehr wirklich nützlich. Die metaphorische feine, unter Umständen getarnte Klinge, ist nicht mehr notwendig, wenn man stattdessen ohne Probleme auf die wörtliche Granate zurückgreifen kann.</p>
<p class="block">Dort, wo es zu Angriffen auf ukrainische IT-Netzwerke kam, trafen die Angreifer:innen auf einen Gegner, der die letzten Jahre damit verbracht hat seine Systeme zu härten und gemachte Erfahrungen aus erfolgreichen Angriffen in die Praxis umzusetzen.</p>
<p class="block">Ich hatte die Chance, mich letztes Jahr auf einer Konferenz ausführlich mit dem Sicherheitsverantwortlichen einer ukrainischen Regierungsbehörde zu unterhalten. Eine Aussage, die mir (sinngemäss) im Gedächtnis geblieben ist, war: "Wir wehren pro Monat mehr Angriffe ab als die meisten Unternehmen in mehreren Jahren mitbekommen".</p>
<p class="block">Unabhängig davon, wie extrem die Diskrepanz nun tatsächlich ist, die Ukraine ist insbesondere seit 2014 und den Ereignissen auf der Krim und im Osten des Landes verstärkt Ziel russischer Cyberangriffe. Gerade zu Beginn waren die Angreifer:innen ob der veralteten und desolaten IT-Landschaft des Landes, sowohl bei staatlichen Institutionen als auch bei privaten Unternehmen, enorm erfolgreich. Im Lauf der letzten Jahre hat sich dies massiv geändert, und viele österreichische Unternehmen könnten sich vom Sicherheitsstand bei manchen ukrainischen Unternehmen einiges abschauen.</p>
<p class="block">Neben diesen jahrelangen Erfahrungswerten darf die Unterstützung durch westliche Partner, sowohl durch diverse Nachrichtendienste als auch eine Vielzahl von kommerziellen Unternehmen, nicht außer Acht gelassen werden.</p>
<p class="block">Das Übertragen von kritischen Daten der ukrainischen Behörden, die flächendeckende Bereitstellung von Endpoint Protection für ukrainische Systeme, eine vermutlich gigantische Menge an Informationen und generell intensiver Informationsaustausch und Kooperation haben sicherlich einen massiven Beitrag zur Stärkung der Resilienz ukrainischer Systeme geleistet.</p>
<p class="block">Was genau von nachrichtendienstlicher Seite beigetragen wurde kann ich nicht sagen, aber ich bin mir relativ sicher, dass deren Bedrohungsinformationen das Gegenteil von nutzlos waren. Und wenn wir schon beim Stichwort Nachrichtendienste sind ..</p>
<h3 class="block">Spionage?</h3>
<p class="block">Ich habe zu Beginn dieses Beitrages gesagt, dass ich digitale Spionage mehr oder weniger ignoriert habe. Auch wenn ich das Thema persönlich sehr spannend finde, unsere Aufgabe als nationales CERT ist die IT-Sicherheit, und darauf liegt auch unser Fokus.</p>
<p class="block">Dazu kommt, dass die Informationslage (was öffentliche Quellen betrifft) sehr dürftig ist, und viel Spekulation erfordern würde. Auch was destruktive Angriffe betrifft ist die Vollständigkeit der zur Verfügung stehenden Informationen mehr als fraglich, aufgrund der ausgezeichneten Arbeit von Sicherheitsunternehmen, unabhängigen Forscher:innen und Expert:innen sowie einigen Veröffentlichungen von Regierungsbehörden zumindest etwas besser.</p>
<p class="block">Dennoch möchte ich kurz auf Informationsgewinnung durch Cyberangriffe eingehen, damit hier nicht der falsche Eindruck entsteht, dass russische Aktivitäten hier erfolgreich waren, eben weil destruktive Angriffe es nicht waren. Ich bin mir sicher, dass es im Rahmen des Krieges zu ungezählten Fällen von Cyberspionage gekommen ist, ich zweifle aber durchaus an, dass diese in militärischer Hinsicht wirksamer waren als destruktive Angriffe.</p>
<p class="block">Es gibt einige wenige Hinweise, dass bei Cyberangriffen Informationen beschafft wurden, die in weiterer Folge zur Koordination von Angriffen verwendet wurden. Microsoft spricht beispielsweise in <a href="https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE50KOK" target="_blank">einem Bericht</a> von Angriffen im Frühjahr 2022 gegen die Verwaltung der Stadt Vinnytsia, deren Flughafen zwei Tage später von mehreren Mittelstreckenraketen getroffen wurde.</p>
<p class="block">Derselbe Vorfall wird in einem <a href="https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RE4Vwwd" target="_blank">zweiten Bericht</a> ebenfalls erwähnt, wobei Microsoft in jenem selbst davon spricht, dass es sich hier um eine zeitliche Korrelation handelt, und nicht notwendigerweise um einen Kausalzusammenhang.</p>
<p class="block">Natürlich ist es denkbar, dass militärische relevante Daten im Zuge von Angriffen gegen IT-Systeme im Einsatzgebiet erbeutet wurden. Für die Kommandeurin einer Militäreinheit wäre es allerdings deutlich einfacher und wahrscheinlich schneller zielführend, eine billige Drohne einzusetzen und die gegnerischen Stellungen auszukundschaften anstatt zu warten, bis zufällig auf einem gegnerischen Computer eine Karte aller Stellungen gefunden wird.</p>
<p class="block">Alternativ kann ein Unteroffizier vielleicht auf Satellitenbilder, mobile Radareinheiten, akustische Anti-Artillerie-Geräte und sonstige Technik zurückgreifen - oder einfach die aus dem Nachbarort radelnde Pensionistin fragen, ob sie am Hauptplatz zufällig Panzer gesehen hat.</p>
<p class="block">Dazu kommt, dass durch alle Beteiligten auf allen Seiten - Soldat:innen, Journalist:innen, Zivilist:innen - eine Menge an audiovisuellen Inhalten generiert und in den sozialen Netzwerken geteilt wurde. Auch daraus lassen sich, unter Umständen schneller, billiger und einfacher, operative Informationen gewinnen.</p>
<p class="block">Abgesehen davon, dass man mit einer gewissen Sicherheit davon ausgehen kann, dass digitale Spionageoperationen unter denselben Problemen und Limitierungen gelitten haben, wie destruktive Angriffe, sind Cyberangriffe auf operativer Ebene, im Feld, wohl nicht das Mittel der Wahl.</p>
<h3 class="block">Was heißt das alles für uns als Verteidiger?</h3>
<p class="block">Mein Vorgesetzter hat diese seltsame, fixe Vorstellung, dass ich auf Basis unvollständiger Informationen Aussagen über vergangene und zukünftige Entwicklungen treffe. Er nennt das "Analyse" und behauptet, dass ich dafür bezahlt werde. Woher auch immer er das wieder hat.</p>
<p class="block">Das Gros der "lessons learned" ist für die meisten Unternehmen wahrscheinlich von geringerer Bedeutung als für militärische Planer. Der bisherige Verlauf des Krieges in der Ukraine hat gezeigt, dass es eine gigantische Herausforderung ist, kontinuierlich Cyberangriffe durchzuführen, die zielgerichtet, zweckdienlich und effektiv sind. Diese dann auch noch so zu gestalten, dass sie die kinetischen Operationen der eigenen Truppen unterstützen ist unter Umständen sogar noch eine grössere Herausforderung.</p>
<p class="block">Dennoch gibt es auch für den zivilen Bereich, für den Unternehmensalltag, einige (auch von uns seit langem beschworene) Dinge, die sich im Rahmen des Ukrainekrieges erneut als wahr herausgestellt haben.</p>
<p class="block">Sorgfältige Vorbereitungsarbeit und kontinuierliche Verbesserung der Sicherheit der eigenen Netzwerke funktioniert. Investitionen in diesem Bereich mögen zwar eine Kostenstelle sein, sind aber langfristig kritisch für die Gewährleistung des regulären Betriebes des eigenen Unternehmens.</p>
<p class="block">Der Fokus dieser Investitionen, sowohl monetärer als auch personeller Natur, sollte auf den Grundlagen liegen. In den seltensten Fällen kommt es bei Cyberangriffen zum Einsatz von fundamental neuen Angriffsmethoden, in den meisten Fällen wird auf altbewährte Taktiken und Techniken zurückgegriffen. Dies gilt auch in Extremfällen, wie das ukrainische SSSCIP in einer <a href="https://cip.gov.ua/en/news/kiberataki-artileriya-propaganda-zagalnii-oglyad-vimiriv-rosiiskoyi-agresiyi" target="_blank">Analyse zu der Dimension russischer Cyberangriffe</a> festgestellt hat.</p>
<p class="block">Threat Hunting zu betreiben, ein hypermodernes SOC zu haben oder "Artificial Intelligence" einzusetzen ist alles schön und gut, hilft aber wenig, wenn es ein einziges lokales Adminpasswort für alle Systeme gibt oder das Buchhaltungsprogramm auf Windows XP (ohne Service Pack) angewiesen ist.</p>
<p class="block">Gleichzeitig kennen Cyberangriffe keine Regeln, sie halten sich an keine sozialen Konventionen oder internationalen Normen. Kriminelle interessieren sich in keinster Weise für ISO-Zertifizierungen (es sei denn, sie machen sich auf ihren Leak-Seiten explizit darüber lustig), und in den seltensten Fällen haben Gesetze irgendeine Relevanz für die Täter:innen.</p>
<p class="block">Jedes Unternehmen, jede Institution, jede Organisation ist ein legitimes Ziel, solange es für die Angreifer:innen - auf welche Art und Weise auch immer - gewinnbringend ist. Selbst wenn Bedrohungsakteure vorgeben, gewisse Gruppen von Zielen nicht anzugreifen (wie dies zuletzt bei <a href="https://flashpoint.io/blog/clop-ransomware-moveit-vulnerability/" target="_blank">Angriffen der Clop Ransomwaregang</a> der Fall war) heißt das noch lange nicht, dass dem dann im Endeffekt auch wirklich so ist.</p>
<p class="block">Was sich allerdings in der Zeit seit dem Beginn des Krieges in der Ukraine geändert hat, jedoch nicht notwendigerweise im Kausalzusammenhang steht: In der Vergangenheit waren Informationsoperationen nahezu ausschließlich die Domäne von Nationalstaaten, oder organisierten Gruppierungen (beispielsweise Unternehmen oder politische Parteien), und in den meisten Fällen war die Zielsetzung eine Form von politischer Einflussnahme.</p>
<p class="block">In den letzten Monaten zeigt sich vor allem bei finanziell motivierten Cyberangriffen eine Bereitschaft der Täter, den Verhandlungs- und Zahlungsdruck durch gezieltes Ansprechen von Medien, vor allem soziale Medien aber auch "traditionelle" Nachrichtenorganisationen, und die schrittweise Veröffentlichung von angeblich gestohlenen Informationen, zu erhöhen.</p>
<p class="block">Dies steht im Gegensatz zu der fast schon kommentarlosen Veröffentlichung von betroffenen Unternehmen auf den jeweiligen Leakseiten. Es ist dementsprechend durchaus ratsam, die eigene Kommunikationsabteilung frühzeitig in den Incident Response-Prozess einzubeziehen und eine Kommunikationsstrategie in der Hinterhand zu haben. Nach einem Sicherheitsvorfall transparent und ehrlich mit Betroffenen, Kunden und der breiteren Öffentlichkeit zu kommunizieren ist unschätzbar wertvoll, und interessanterweise etwas, was gerade große Unternehmen so überhaupt nicht auf die Reihe kriegen.</p>
<hr />
<p class="block">Auch wenn meine Einschätzung sich mit weiten Teilen der Community deckt - ich empfehle an dieser Stelle das ausgezeichnete <a href="https://carnegieendowment.org/2022/12/16/russia-s-wartime-cyber-operations-in-ukraine-military-impacts-influences-and-implications-pub-88657" target="_blank">Paper</a> das Jon Bateman im Rahmen seiner Arbeit für das <a href="https://carnegieendowment.org/" target="_blank">Carnegie Endowment for International Peace</a> geschrieben hat, welches sich mit sehr ähnlichen Fragen beschäftigt (und dabei deutlich detaillierter und qualitativer ist) - sei fairerweise erwähnt, dass es Expert:innen gibt, die das anders sehen.</p>
<p class="block">Der Leiter des britischen GCHQ bezeichnet die Verneinung des Einflusses russischer Cyberangriffe als "<a href="https://www.economist.com/by-invitation/2022/08/18/the-head-of-gchq-says-vladimir-putin-is-losing-the-information-war-in-ukraine" target="_blank">Irrtum</a>". Und auch aus den Reihen der NATO kommen <a href="https://www.foreignaffairs.com/articles/ukraine/2022-04-06/myth-missing-cyberwar" target="_blank">Stimmen</a>, die Cyberangriffe als den grössten militärischen Erfolg Russlands seit Beginn des Krieges betrachten - der Sicherheitsexperte Dmitri Alperovitch sieht dies, bezogen auf den Angriff gegen KA-SAT zu Beginn des Krieges, <a href="https://twitter.com/DAlperovitch/status/1562560980105584640" target="_blank">gleich</a>. Auch wenn ich natürlich gerne die absolute Wahrheit für mich gepachtet hätte, wahrscheinlich liegt genau jene in irgendeinem der vielen Grautöne zwischen den binären Beurteilungen.</p>
<p class="block">Abschließend sei gesagt: Ich will in keinster Weise in Abrede stellen, dass russische Nachrichtendienste kontinuierlich in ihre offensiven Kapazitäten investieren und eine Bedrohung für österreichische Ziele darstellen (selbiges gilt natürlich auch für andere Bedrohungsakteure, mit deren gesteigerter Aktivität sich mehr als ein eigener Beitrag füllen ließe ..), dass Cyberangriffe gegen kritische Infrastruktur eine ernst zunehmende Bedrohung sind, oder dass OT-Systeme ein immer lohnenderes Ziel für Angriffe werden. All dies steht hoffentlich nicht zur Debatte.</p>
<p class="block">Aber gerade um den Schutz dieser kritischen Systeme bestmöglich zu gewährleisten ist es in meinen Augen wichtig, einem objektiven, rationalen Ansatz zur Einschätzung der Bedrohungen und Risiken zu verfolgen - und nicht in Hyperbeln zu verfallen oder diesen zu folgen.</p>CERT.at2023-06-28T18:22:00Z3CX - Operation erfolgreich, Patient ignoriertCERT.at2023-04-13T20:19:01Z2023-04-13T19:13:00Z<p class="block">3CX hat nun <a href="https://www.3cx.de/blog/mandiant-erste-ergebnisse/" target="_blank">erste Informationen veröffentlicht</a>, welche durch Mandiant im Rahmen einer forensischen Untersuchung der Systeme des Unternehmens gefunden wurden. Diese Informationen unterstützen Aussagen in Berichten von anderen Sicherheitsunternehmen (wie beispielsweise <a href="https://securelist.com/gopuram-backdoor-deployed-through-3cx-supply-chain-attack/109344/" target="_blank">Kaspersky</a>), die den Angriff gegen 3CX beziehungsweise den dafür verantwortlichen Bedrohungsakteur staatlichen Stellen in Nordkorea zurechnen.</p>
<p class="block">Inzwischen gibt es auch eine vergleichsweise brauchbare Liste an Artefakten und technischen Indikatoren, mithilfe derer sich eine Infektion im eigenen Netzwerk relativ zuverlässig erkennen lässt. Links zu dem Gros dieser Indikatoren finden sich in unserer <a href="https://cert.at/de/aktuelles/2023/4/weitere-informationen-zu-angriffen-gegen-3cx-desktop-app" target="_blank">letzten Veröffentlichung zum Thema 3CX</a>.</p>
<p class="block">Nach anscheinender anfänglicher Schockstarre hat das Unternehmen auch seine Krisenkommunikation inzwischen halbwegs im Griff, neben "offiziellen" Pressemeldungen hat sich auch der Geschäftsführer von 3CX bereits mehrfach persönlich zu der Causa zur Sache gemeldet. Dies unter anderem in einem <a href="https://www.3cx.com/community/threads/security-incident-update-april-4-2023.120075/" target="_blank">Posting im firmeneigenen Forum</a>. Folgender Teil dieses Beitrages sticht dabei hervor:</p>
<blockquote>
<p class="block"><strong>We only have a handful of cases reported to us where malware has actually been triggered</strong>. And these reports still require verification. Furthermore after removal of the infected files using anti virus software no further malicious outbound traffic has been observed. Of course this may change but this is the status as of today.</p>
</blockquote>
<p>Mal ganz abgesehen davon, dass diese Aussage im Widerspruch zu dem steht, was in weiterer Folge von Kund:innen in eben jenem Forenthread berichtet wird, und auch elegant ausblendet, dass die kompromittierte Version der 3CX Desktop-App per Definition auch Malware ist - hier wird ein ganz wesentlicher Punkt ignoriert. Ein Punkt, den auch Teile der Security-Community zu ignorieren scheinen.</p>
<p>Ja, nach allem was wir bisher wissen handelt es sich bei den Angreifer:innen tatsächlich um einen staatlichen Bedrohungsakteur dem es zumindest aktuell nicht darum gehen dürfte, weitreichend zerstörerische Schadsoftware auszurollen - auch wenn nordkoreanische Angreifer:innen in der Vergangenheit auch destruktiv unterwegs waren, so waren in den letzten Jahren Spionage und der Diebstahl von Kryptowährungen doch eher im Fokus der Aktivitäten.</p>
<p>Und ja, eben jene Theorie, dass die Angreifer:innen als aktuelles Primärziel das Eindringen in einen Finanzdienstleister, einen Exchange oder ein sonstiges Unternehmen im Finanzbereich hatten ist absolut plausibel. Das heisst aber noch lange nicht, dass dies das einzige Ziel ist oder war, dieser durch die Kompromittierung von 3CX erstandene weitreichende Zugriff kann durch den Bedrohungsakteur vielfältig genutzt werden. Es wäre fast schon nachlässig verschwenderisch, aus Sicht der Angreifer:innen, wenn diese das nicht auch entsprechend tun würden.</p>
<p class="block">Selbst wenn das Unternehmen ein vermeintlich "sauberes" Update nachgeliefert hat, und Mandiant anscheinend mit Hochdruck dabei ist, forensische Untersuchungen durchzuführen, ist es in meinen Augen beinahe fahrlässig, diesen Sicherheitsvorfall als beendet anzusehen und zur digitalen Tagesordnung zurückzukehren. Insbesondere in Anbetracht der Tatsache, dass bisherige technische Analysen (wie beispielsweise die sehr empfehlenswerte der <a href="https://objective-see.org/blog/blog_0x74.html" target="_blank">kompromittierten macOS-Variante der 3CX Desktop App</a>) deutliche Hinweise darauf liefern, dass eben jene vielfältige Nutzung zumindest in der Theorie angedacht war oder ist:</p>
<blockquote>
<p>That’s up to say, the [supply-chain] attacker gets thousands of victims, collects everything they need for future compromises, profiles their haul, and decides how to maximize that access.</p>
</blockquote>
<p class="block">Wir haben in unserer Rolle als nationales CERT von Partnerorganisationen Informationen über ungefähre Infektionszahlen bekommen. Diese Zahlen dürfen wir leider nicht veröffentlichen, und sie beziehen sich auch nicht speziell auf Österreich, sondern auf weltweite Infektionen, ohne detailliertere Aufschlüsselungen zu beinhalten. Aber, um irgendwo den Spagat zwischen Wahrung der Informationsklassifikation und dem Wunsch nach der Weitergabe relevanter Informationen zu bewerkstelligen, es ist eine Zahl, die deutlich über dem Eurobeitrag liegt, den mir mein Arbeitgeber am Ende jeden Monats auf mein Konto überweist.</p>
<p class="block">Daher die eindringliche Bitte: Auch wenn es verlockend ist, weil wir allesamt genug zu tun haben, wenn die 3CX Desktop App in Ihrem Unternehmen im Einsatz ist, oder innerhalb der letzten Monate im Einsatz war, überprüfen Sie Ihre Risikoabschätzung, versuchen Sie sicher zu stellen, dass Sie nicht von einer Infektion betroffen waren, oder zumindest von Seiten der Angreifer:innen keine weiteren missbräuchlichen Schritte gesetzt wurden. Ja, das ist eine Investition von Zeit und Arbeitskraft - aus eigener Erfahrung weiss ich aber, dass die Aufarbeitung einer mehrere Monate lang unentdeckt gebliebenen Kompromittierung deutlich mehr kostet. In jeder Hinsicht.</p>
<hr />
<p class="block">Und ganz allgemein auch noch der Appell: Wenn Ihr Unternehmen bei solchen Vorfällen Opfer wird, oder der Verdacht besteht, dass es zu einer Infektion oder Kompromittierung gekommen ist, bitte sprechen Sie mit uns - in vielen Fällen haben wir die Möglichkeit, ihre Incident Response zumindest mit technischen Detailinformationen zu unterstützen. Und selbst in Situationen wo uns dies nicht möglich ist erlaubt uns das Wissen über den Vorfall eine bessere Abschätzung der aktuellen Situation in Österreich. Sie wissen schon, dieses medial gerne ausgeschlachtete "Cyberlagebild".</p>CERT.at2023-04-13T19:13:00Z(Gepatchte aber dennoch) üble Sicherheitslücke in (einer optionalen Komponente von) Microsoft WindowsCERT.at2023-04-12T19:27:42Z2023-04-12T19:08:00Z<p class="block">Es entbehrt nicht einer gewissen Ironie, dass die meisten Blogeinträge, welche sich in den letzten Monaten mit Sicherheitslücken in Produkten von Microsoft beschäftigt haben, von dem Mitarbeiter des CERT stammen, dessen Kenntnisse rund um Windows, Office und den ganzen Rest wohl mit Abstand am schwächsten sind - und damit herzlich willkommen zu einem weiteren Beitrag, welcher diese Kriterien vollständig erfüllt.</p>
<p class="block">Dass die monatlichen Patchdays für das Gros der Unternehmen in den meisten Fällen unter "business as usual" fallen habe ich bereits <a href="https://cert.at/de/blog/2022/12/patch-tuesday-zur-abwechslung-augen-auf" target="_blank">im Dezember letzten Jahres angemerkt</a>. In der damals angesprochenen Zwickmühle sind wir jedoch leider auch dieses Monat wieder gelandet, dank <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21554" target="_blank">CVE-2023-21554</a>. Dabei handelt es sich um eine Remote Code Execution im "Windows message queuing service", einer optionalen Komponente von Windows.</p>
<p class="block">Wie das Wort "optional" andeutet ist diese zwar nicht standardmäßig aktiviert, jedoch laut Microsoft in jeder Version von Windows, inklusive Windows 11 und Windows Server 2022, inkludiert. Wenn der Service aktiv ist lauscht er auf Port 1801/TCP auf neue Verbindungen, was geneigte Angreifer:innen dank dieser Sicherheitslücke sehr freut, weil es folgendes ermöglicht:</p>
<blockquote>
<p class="block">To exploit this vulnerability, an attacker would need to send a specially crafted malicious MSMQ packet to a MSMQ server. This could result in remote code execution on the server side.</p>
</blockquote>
<p class="block">Autsch. Ich habe im Lauf meiner professionellen Laufbahn schon öfter gewitzelt, Systeme seien "so unsicher, dass man sie nur anhusten müsse, damit sie in sich zusammenbrechen". Auch wenn die genauen technischen Details (zumindest mir) noch nicht bekannt sind, so kommt CVE-2023-21554 dem von mir humoristisch gezeichneten Szenario doch sehr, sehr nahe.</p>
<p class="block">Die Sicherheitsforscher:innen von Checkpoint sprechen in <a href="https://research.checkpoint.com/2023/queuejumper-critical-unauthorized-rce-vulnerability-in-msmq-service/" target="_blank">einem Blogpost</a> von weltweit rund 360.000 öffentlich erreichbaren IP-Adressen, bei denen sich hinter einem offenen Port 1801/TCP ein laufender MSMQ-Service verbirgt. Diese massiven Zahlen konnte ich auf die Schnelle nicht verifizieren, aber es gibt definitiv einen Haufen potentiell betroffener Systeme da draussen. Und auch wenn ich (leider/zum Glück) keinen Einblick in die Denkweise der diversen aktuell aktiven Bedrohungsakteure habe, so würde es mich sehr wundern, wenn sich Angreifer:innen die Ausführung von Code über einen simpel abzusetzenden Request lange entgehen lassen würden.</p>
<p class="block">Neben der offensichtlichen Lösung für das Problem - das Einspielen des zur Verfügung stehenden Patches - sei Administratoren dringend geraten zu prüfen, ob der betroffene Service (laut Microsoft ist er unter dem Namen "Message Queuing" / "mqsvc.exe" zu finden) auf einem der eigenen Systeme aktiv ist.</p>
<p class="block">Und selbst wenn beim Lesen dieser Zeilen der Gedanke "Ha! Sowas würde ich doch nie aktivieren!" kommen sollte, so wäre ich doch vorsichtig. Anscheinend wird MSMQ als Middleware in diversen populären Anwendungen eingesetzt, was dazu führen kann, dass der Service aktiviert wird, ohne dass Benutzer:innen oder Administrator:innen sich dessen bewusst sind.</p>
<p class="block">Doch selbst wenn man im eigenen Unternehmen nicht durch Dritte sabotiert wird, so ist Microsoft unter Umständen zur Stelle und <a href="https://research.checkpoint.com/2023/queuejumper-critical-unauthorized-rce-vulnerability-in-msmq-service/" target="_blank">schiesst einem motiviert in's Bein</a>:</p>
<blockquote>
<p>For example, CPR saw that when installing the official Microsoft Exchange Server, the setup wizard app would enable the MSMQ service in the background if the user selects the “Automatically install Windows Server roles and features that are required to install Exchange” option, which is recommended by Microsoft.</p>
</blockquote>
<p class="block">Sollte nichts der genannten Dinge zutreffen und MSMQ trotzdem aktiviert sein .. nun, ich will hier nicht die Ansicht vertreten, dass Protokolle, Software oder Systeme, die lange keine Aktualisierung mehr erfahren haben deswegen schlecht, veraltet oder gar unsicher sind. Dass die <a href="https://learn.microsoft.com/en-us/previous-versions/windows/desktop/msmq/ms703216(v=vs.85)" target="_blank">offizielle Dokumentation zu MSMQ</a> anscheinend das letzte Mal vor weit mehr als fünf Jahren geändert wurde, und <a href="https://particular.net/blog/msmq-is-dead" target="_blank">bereits 2020 davon gesprochen wurde</a>, dass MSMQ wohl tot sei, hinterlässt aber zugegebenerweise einen etwas bitteren Beigeschmack.</p>
<p class="block">Vielleicht übersehe ich hier ob meiner mangelnden intimen Bekanntschaft mit Windows ein Szenario, in der MSMQ systemrelevant ist, aber unter Umständen sollte man diese Schwachstelle zum Anlass nehmen, den Service in den wohlverdienten Ruhestand zu schicken und zu deaktivieren. Oder zumindest firewall-seitig sicherstellen, dass Port 1801/TCP nicht für Gott und die Welt offen erreichbar ist.</p>CERT.at2023-04-12T19:08:00ZIn eigener Sache: CERT.at sucht VerstärkungCERT.at2023-03-28T19:45:02Z2023-03-28T19:42:00Z<p class="block">Für unsere täglichen Routineaufgaben suchen wir derzeit <strong>1 Berufsein- oder -umsteiger:in</strong> mit ausgeprägtem Interesse an IT-Security, welche:r uns bei den täglich anfallenden Standard-Aufgaben unterstützt. Details finden sich auf <a title="https://cert.at/de/ueber-uns/jobs/" href="https://cert.at/de/ueber-uns/jobs/" target="_blank">unserer Jobs-Seite</a>.</p>CERT.at2023-03-28T19:42:00ZCVE-2023-23397 - der (interessante) Teufel steckt im DetailCERT.at2023-03-15T18:02:58Z2023-03-15T16:56:00Z<p class="block">Im Regelfall veröffentlichen wir zu Sicherheitslücken, die durch den Hersteller im Rahmen eines regulären Patchzyklus behoben werden, keine Warnung. Die Motivation dahinter ist, dass wir unsere Warnungen als Werkzeug betrachten, Informationen über kritische Schwachstellen mit entsprechender Urgenz an die jeweiligen Adressat:innen bringen wollen. Dementsprechend entscheiden wir relativ konservativ, wovor oder worüber wir warnen, um die Wirkung selbiger nicht zu verwässern.</p>
<p class="block">Aber, wie so oft, bestätigen Ausnahmen die Regel - der im Rahmen des diesmonatigen Patchday von Microsoft veröffentlichte Fix für CVE-2023-23397 ist genau so ein Fall. Die weite Verbreitung von Microsoft Outlook, kombiniert mit der vergleichsweise trivialen Ausnutzbarkeit sowie des laut dem Unternehmen bereits erfolgten Missbrauches der Schwachstelle bei Angriffen ist ein ausreichender Motivator um mit absolutem Nachdruck zu sagen: Aktualisierung einspielen. <em>Jetzt</em>.</p>
<p class="block">Um, zumindest zu einem gewissen Grad, sicherstellen zu können, dass man nicht bereits Opfer einer Ausnutzung wurde, lässt sich das Script verwenden, welches das Unternehmen aus Redmond im selben Atemzug mit dem Patch <a href="https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-23397/" target="_blank">veröffentlicht hat</a>. Damit lassen sich Exchange-Server auf Spuren einer Kompromittierung von Zugangsdaten untersuchen - indem Mails und Kalendereinträge auf darin vorhandene UNC-Pfade durchleutet werden.</p>
<p class="block">Neben technischen Informationen zu CVE-2023-23397 enhält das <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23397" target="_blank">Advisory zu der Sicherheitslücke</a> diversen Metriken, sowie Empfehlungen zur Risikominimierung und noch einige andere Informationen. Wo sich Microsoft aber in einen Mantel des Schweigens hüllt sind Details zu der berichteten bereits erfolgten Ausnutzung - Information, die nicht unwichtig ist.</p>
<p class="block">Für die eigene Risikobewertung ist es durchaus von Relevanz, ob die Schwachstelle durch finanziell motivierte Bedrohungsakteure ausgenutzt wurde, oder ob sie bei nachrichten-/geheimdienstlich gesteuerten Spionagekampagnen missbraucht wurde.</p>
<p class="block">Ein Indikator findet sich in der Danksagung:</p>
<blockquote>
<p class="block">CERT-UA, Microsoft Incident Response, Microsoft Threat Intelligence (MSTI)</p>
</blockquote>
<p class="block"> Deutlichere Worte findet das Unternehmen in <a href="https://msrc.microsoft.com/blog/2023/03/microsoft-mitigates-outlook-elevation-of-privilege-vulnerability/" target="_blank">einem Blogpost</a>:</p>
<blockquote>
<p class="block">Through joint efforts, Microsoft is aware of limited targeted attacks using this vulnerability and initiated communication with the affected customers. Microsoft Threat Intelligence assesses that a Russia-based threat actor used the exploit patched in CVE-2023-23397 in targeted attacks against a limited number of organizations in government, transportation, energy, and military sectors in Europe.</p>
</blockquote>
<p class="block">Ich lehne mich mal vorsichtig aus dem Fenster und deduziere, dass die Entdeckung der Schwachstelle im Rahmen einer forensischen Untersuchung der ukrainischen CERT-Kollegen erfolgt ist und in weiterer Folge Microsoft gemeldet wurde - was an und für sich gesprochen schon erfreulich ist. Nicht nur, weil die Kooperation zwischen staatlichen Stellen und Herstellern wohl nicht immer einfach ist, und die Beeinträchtigungen, die die Arbeit in einem aktiven Kriegsgebiet mit sich bringt. Sondern auch, weil es eine meiner (von mir gerne salopp als Tatsache deklarierte) Theorien unterstützt.</p>
<p class="block">Ich höre auf Konferenzen und in Gesprächen mit Kolleg:innen aus der Branche immer wieder die Aussage, dass sich Angreifer:innen gar nicht bemühen müssten, weil die trivialen Techniken und billigen Tricks ausreichen würden.</p>
<p class="block">Aber auch Witze und Gelächter über russische Bedrohungsakteure und ihre Aktivitäten seit Beginn des russischen Angriffskrieges gegen die Ukraine sind keine Seltenheit - insbesondere, weil deren Performance im Rahmen offensiver Computer-Netzwerk-Operationen in der öffentlichen Wahrnehmung ähnlich bescheiden ist, wie die der russischen Streitkräfte gerade zu Beginn der seit über einem Jahr andauernden dreitägigen Spezialoperation.</p>
<p class="block">Die Geschehnisse rund um die Entdeckung von CVE-2023-23397 zeigt für mich, dass Beides fälschliche Annahmen sind. Natürlich freuen sich Angreifer:innen, wenn die Kompromittierung ihrer Ziele ohne großen Aufwand möglich ist. Aber sie scheuen ganz sicher nicht davor zurück zu komplexen Angriffsmethoden oder zur "Verbrennung" bisher unbekannter Schwachstellen zu greifen, wenn die einfachen Methoden nicht funktionieren oder nicht im erwünschten Ausmaß erfolgversprechend sind. Alles ist erlaubt, solange es die Erreichung der Ziele unterstützt.</p>
<p class="block">Ja, die von einer Vielzahl von "Expert:innen" angekündigte "digitale Zerstörungswelle" gegen europäische Netzwerke und Computersysteme ist ausgeblieben. Und ja, manche der enttarnten (oder, im Fall diverser pseudo-hacktivistischer Gruppierungen, öffentlich angekündigten) Angriffsversuche Russland zugerechnteter Bedrohungsakteure waren schon fast lachhaft tollpatschig. Aber in jedem Konflikt gilt, dass es niemals eine gute Idee ist, seine Widersacher zu unterschätzen - das wusste schon Sunzi .. oder Carl von Clausewitz. Auf jeden Fall bin ich sicher nicht der Erste, der das propagiert.</p>
<hr />
<p class="block">Oh, und weil's eine billige Gelegenheit ist: Diese Schwachstelle ist ein erneutes, eindrucksvolles Beispiel, warum sowohl "Defense in Depth" als auch 2FA wichtige Komponenten der eigenen Sicherheitsstrategie sind. Es gab, bis zu der Veröffentlichung des Patches, relativ wenig, was man gegen einen Missbrauch der Schwachstelle hätte tun können. Aber auch der coolste gestohlene Net-NTLMv2-Hash hilft Angreifer:innen wenig, wenn der dazugehörige zweite Faktor sicher verwahrt auf einem Hardwaretoken in der Hosentasche der eigenen Mitarbeiter:innen ist.</p>CERT.at2023-03-15T16:56:00ZProxyNotShell Mitigations K.O.CERT.at2023-01-05T14:03:22Z2023-01-05T14:00:00Z<p class="block">Warum ist ProxyNotShell noch ein Thema? Die Schwachstellen wurden doch von Microsoft<a title="https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/" href="https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/" target="_blank"> Anfang November geschlossen</a>?</p>
<p class="block">Kurz gesagt, weil sich viele auf die letzte Mitigation von Microsoft verlassen haben, anstatt auf den <a title="https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2022-exchange-server-security-updates/ba-p/3669045" href="https://techcommunity.microsoft.com/t5/exchange-team-blog/released-november-2022-exchange-server-security-updates/ba-p/3669045" target="_blank">November-Patch</a>. Der Exchange Patch vom November hatte es einigermaßen in sich. Zuerst war er heiß erwartet, dann gab es vereinzelt doch Probleme beim Einspielen und hat so manchen Admin mehrere Anläufe gekostet. Zum Glück hat Microsoft Übergangslösungen für die ProxyNotShell-Sicherheitslücke veröffentlicht … Naja.</p>
<p class="block">Ende September 2022 bekam die Schwachstellenkette (CVE-2022-41040 und CVE-2022-41082) ihren Namen <a title="https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9?gi=9fd90271d6ef" href="https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9?gi=9fd90271d6ef" target="_blank">ProxyNotShell</a>, hier <a title="https://cert.at/de/warnungen/2022/11/0-day-exploit-remote-code-execution-in-microsoft-exchange-on-premise-workaround-verfugbar" href="https://cert.at/de/warnungen/2022/11/0-day-exploit-remote-code-execution-in-microsoft-exchange-on-premise-workaround-verfugbar" target="_blank">unsere Warnung</a> dazu. Was folgte war ein Katz- und Maus-Spiel, in dem Microsoft eine Mitigation nach der anderen veröffentlichte, die meist kurze Zeit danach wieder umgangen werden konnte. Die letzte Mitigation vom 8. Oktober blieb dann erst einmal standhaft und das sogar bis über den November-Patch hinaus. Diese Mitigation wurde aber dann Mitte Dezember wieder <a title="https://www.crowdstrike.com/blog/owassrf-exploit-analysis-and-recommendations/" href="https://www.crowdstrike.com/blog/owassrf-exploit-analysis-and-recommendations/" target="_blank">erfolgreich umgangen</a> was ungepatchte Exchange-On-Premise-Server wieder angreifbar machte. Das hat zur Folge, dass <a title="https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-exchange-server-report/" href="https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-exchange-server-report/" target="_blank">Shadowserver</a> in Österreich zum jetzigen Zeitpunkt rund <a title="https://dashboard.shadowserver.org/statistics/combined/time-series/?date_range=30&source=scan%2Bscan6&tag=exchange&geo=AT&style=stacked" href="https://dashboard.shadowserver.org/statistics/combined/time-series/?date_range=30&source=scan%2Bscan6&tag=exchange&geo=AT&style=stacked" target="_blank">1600 vulnerable Systeme</a> erkennt. „Fatality“</p>
<p class="block">Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen. Regelmäßige Neustarts stellen sicher, dass diese auch zeitnah aktiviert werden.</p>CERT.at2023-01-05T14:00:00ZWarum ich keine Cloud-basierten Passwort-Manager nutze:CERT.at2022-12-30T11:52:10Z2022-12-30T12:00:00Z<p class="block">Eingangs <a href="https://i.imgflip.com/2x3gah.jpg">ein</a> <a href="https://i.pinimg.com/236x/64/08/32/64083250e48223e94387ee3ba45c09c6.jpg">paar</a> <a href="https://i.imgflip.com/wis6l.jpg">seichte</a> <a href="https://i.imgflip.com/22mmkf.jpg">Witze</a> über die Cloud. Wie Sie hiesigen Medienberichten [<a href="https://www.golem.de/news/sicherheitsforscher-lastpass-wegen-pr-und-luegen-kritisiert-2212-170807.html">1</a>, <a href="https://www.theverge.com/2022/12/28/23529547/lastpass-vault-breach-disclosure-encryption-cybersecurity-rebuttal">2</a>, <a href="https://www.wired.com/story/lastpass-breach-vaults-password-managers/">3</a>, <a href="https://techcrunch.com/2022/12/27/badly-handled-data-breaches-2022/">4</a>] unter Umständen entnommen haben, bekamen LastPass-BenutzerInnen für ihr Vertrauen heuer ein Weihnachtsgeschenk der unerfreulichen Art.</p>
<h3 class="block">Was ist passiert?</h3>
<p class="block">Am 22. Dezember veröffentlichte LastPass das nun dritte Update zu einem <a href="https://blog.lastpass.com/2022/12/notice-of-recent-security-incident/">Security-Advisory</a>, der zugehörige Incident begann irgendwann Anfang August in einer Entwicklungsumgebung.</p>
<p class="block">Damals wurden mithilfe eines kompromittierten Entwicklerkontos sowohl Quellcode als auch interne Infrastrukturdetails entwendet. Dieser Vorfall ist natürlich unangenehm, jedoch relativ gut eingrenzbar (meinte LastPass am 25. August):</p>
<blockquote>
<p class="block">While our investigation is ongoing, we have achieved a state of containment, implemented additional enhanced security measures, and see no further evidence of unauthorized activity.</p>
</blockquote>
<p class="block">Rund 4 Monate später dürfte die Situation etwas eskaliert sein, LastPass schreibt nun, dass neben grundlegenden Benutzerdaten wie Name, Rechnungsadresse, E-Mail auch noch weitaus sensiblere Daten gestohlen wurden:</p>
<blockquote>
<p class="block">The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.</p>
</blockquote>
<p class="block">Ein proprietäres Format, welches unverschlüsselte Felder enthält und durch Backups zu einem Drittanbieter hochgeladen wurde - viel kann da ohnehin nicht mehr falsch gelaufen sein.</p>
<p class="block">Glaubt man dem Twitter-Thread eines ehemaligen LastPass-Mitarbeiters lief dort zumindest in der Vergangenheit einiges nicht ideal. Es gab Ambitionen, Verbesserungen zu erzielen - die Umsetzung ebendieser gestaltete sich jedoch vor allem bei langjährigen Nutzern schwierig.</p>
<blockquote>
<p class="block">Lots of vault entries may be encrypted with ECB mode AES-256. [<a href="https://twitter.com/ejcx_/status/1606428778103709698">4</a>]</p>
</blockquote>
<p class="block">Das ist schlecht. Sehr schlecht. Denn dadurch kann auch ohne Entschlüsselung eine Wiederbenutzung von Passwörtern innerhalb eines Vaults erkannt werden. Die technischen Details erspare ich den LeserInnen an dieser Stelle (<a href="https://www.educative.io/answers/what-is-ecb">hier</a>, und <a href="https://i.imgur.com/CBdiOQ8.png">hier</a>).</p>
<blockquote>
<p class="block">If you had a legacy 5000 rounds or 10000 rounds, the # of rounds can't just be increased server side. [<a href="https://twitter.com/ejcx_/status/1606428775947898881">5</a>]</p>
</blockquote>
<p class="block">Das National Institute of Standards and Technology (NIST) hat im Juni 2017 in ihren "Digital Identity Guidelines" bezüglich der Rundenanzahl "so viel möglich" empfohlen, aber die Empfehlung mit "typischer mindestens 10.000" <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf#page=25">beendet</a>.</p>
<p class="block">Dass das URL-Feld im eigenen Vault <a href="https://twitter.com/ejcx_/status/1606428780351967234">nicht verschlüsselt</a> wird, dürfte bereits länger bekannt sein - das ist also kaum erwähnenswert.<br /><br />Was jedoch erwähnenswert ist: </p>
<h1 class="block">Warum ich keine Cloud-basierten Passwort-Manager nutze</h1>
<p class="block">Grundsätzlich gibt es verschiedene Gründe, warum <span style="text-decoration: line-through;">ich</span> manche Leute die Nutzung eines Cloud-basierten Passwort-Managers ablehnen. Die Gründe dafür sind einfach:</p>
<ul>
<li class="block"><strong>Sicherheit</strong>: Ich möchte meine Passwörter nicht online speichern. Zugegeben: Mein Heimnetzwerk ist wohl ähnlich schlecht abgesichert wie das einiger Cloud-Anbieter - aber es ist meines!</li>
<li class="block"><strong>Privatsphäre</strong>: Dadurch, dass mein Vault nicht online ist, sind meine unverschlüsselten URL-Felder vor fremden Augen geschützt. Und da geht es noch gar nicht um die Möglichkeit der Auswertung oder des Verkaufs meiner Daten.</li>
<li class="block"><strong>Abhängigkeit</strong>: Einerseits von der Verfügbarkeit des Anbieters, andererseits vom "<a href="https://static.wikia.nocookie.net/theitcrowd/images/9/92/FR55S2JG4PBP7TA.MEDIUM.jpg">Internet</a>".</li>
<li class="block"><strong>Kontrolle</strong>: Mit einem Offline-Passwortmanager habe ich vollständige Kontrolle über meine Passwortdatenbank. Die Datenbank landet lediglich auf meinen Geräten und ich muss mich diesbezüglich nicht auf einen Drittanbieter verlassen.</li>
</ul>
<hr />
<h3 class="block">Disclaimer:</h3>
<ul>
<li class="block">Es ist wichtig zu beachten, dass sowohl offlinebasierte als auch cloudbasierte Passwortmanager ihre eigenen Vor- und Nachteile haben. Welche Art für Ihre Bedürfnisse am besten geeignet ist, müssen Sie selbst entscheiden.</li>
<li class="block">Ich benutze <a href="https://keepassxc.org/">KeePassXC</a>, eine Implementierung des quell-offenen <a href="https://keepass.info/">KeePass-Frameworks</a> (sollte ich im neuen Jahr Zeit finden werde ich mir <a href="https://keeweb.info/">KeeWeb</a> in Kombination mit <a href="https://caddyserver.com/docs/quick-starts/reverse-proxy">Caddy</a> und Client-Certificate-Authentication anschauen).</li>
</ul>CERT.at2022-12-30T12:00:00ZPatch Tuesday: (zur Abwechslung) Augen auf!CERT.at2022-12-14T20:38:51Z2022-12-14T20:09:00Z<p class="block">An und für sich ist der monatliche "<a href="https://msrc.microsoft.com/update-guide/releaseNote/2022-Dec" target="_blank">Patch Tuesday</a>" nichts besonderes, und fällt in den meisten Unternehmen wohl sehr eindeutig in die Kategorie "Business as Usual" Auch wir haben uns bereits vor längerer Zeit entschlossen, im Regelfall zu Sicherheitslücken, die im Rahmen dieser Anlässe gefixt werden, keine Warnings zu veröffentlichen. Ausnahmen sind hier relativ selten, zuletzt war dies im <a href="https://cert.at/de/warnungen/2021/7/printnightmare-kritische-sicherheitslucke-in-microsoft-windows-print-spooler-service-workarounds-verfugbar" target="_blank">Juli 2021</a> der Fall, als im Druckerdienst von Windows (zum wiederholten mal) das große Sicherheitschaos ausgebrochen war.</p>
<p class="block">Manchmal gelangen wir jedoch in die verzwickte Lage, dass sich in den Patchnotes Updates für Schwachstellen verbergen, aufgrund derer wir zwar keine Warnung veröffentlichen, aber auf die wir dennoch explizit hinweisen wollen. Diesen Monat ist es wieder einmal soweit.</p>
<p class="block">Konkret geht es um <a href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-41076" target="_blank">CVE-2022-41076</a> sowie <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41080" target="_blank">CVE-2022-41080</a>. Dabei handelt es sich eine Remote Code Execution in Powershell sowie eine Elevation of Privilege in mehreren Versionen von Microsoft Exchange. Sind die beiden Sicherheitslücken für sich alleine zwar unschön, aber kein Weltuntergang, ermöglichen sie in Doppelpack <a href="https://twitter.com/rskvp93/status/1602879250910314496" target="_blank">potentiell eine Codeausführung auf On-Prem Exchange-Servern</a>. Insbesondere wenn man einen ungeschützten Exchange-Server im Netz hat ist hier Eile beim Aktualisieren angebracht (.. aber wer hat das schon, richtig?).</p>
<p class="block">Auch für ein rasches Einspielen des Patches für <a href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-44698" target="_blank">CVE-2022-44698</a> geben wir eine nachdrückliche Empfehlung ab, da diese Lücke bereits aktiv durch Bedrohungsakteure ausgenutzt wird.</p>
<p class="block">Der CVSS-Score von 5.4 ist (in meinen unbedarften Augen) etwas irreführend. Wenn unter Windows eine Datei aus dem Internet heruntergeladen wird, versieht Windows diese Datei mit einem speziellen NTFS-Stream, dem sogenannten "Mark of the Web" - dieser wiederum sorgt dafür, dass manche hauseigenen Applikationen die Datei etwas vorsichtiger behandeln.</p>
<p class="block">Beispielsweise führt Windows SmartScreen, sobald besagte Datei geöffnet wird, basierend auf der Präsenz dieses NTFS-Streams, eine Reputationsprüfung durch. Und genau diese Prüfung kann durch Angreifer:innen, unter Ausnutzung von CVE-2022-44698, umgangen werden. Sich nicht mit Windows SmartScreen herumschlagen zu müssen erleichtert eine initiale Infektion enorm.</p>
<p class="block">Wir können unser eigenes Mantra nicht oft genug betonen:</p>
<blockquote>
<p class="block">Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen. Regelmäßige Neustarts stellen sicher, dass diese auch zeitnah aktiviert werden.</p>
</blockquote>
<p class="block">(Hinter den Gerüchten, dass dieser Paragraph auf den T-Shirts einiger CERT-Mitarbeiter:innen prangt, steckt selbstverständlich kein Körnchen Wahrheit. Nicht ein Einziges.)</p>CERT.at2022-12-14T20:09:00ZOpenSSL wünscht (vielleicht) "Happy Shelloween"CERT.at2022-10-31T15:16:14Z2022-10-31T14:15:00Z<p class="block">Das OpenSSL-Projekt hat für morgen, den 01.11.2022, die Veröffentlichung von Sicherheitsaktualisierungen angekündigt. Diese sollen zwischen 13:00 und 17:00 (UTC) erscheinen und beheben laut der Ankündigung mehrere Sicherheitslücken, darunter eine als "CRITICAL" eingestufte Schwachstelle. Diese Einstufung erfolgte zuletzt 2014, für CVE-2014-0160 - besser bekannt als "Heartbleed".</p>
<p class="block">Aufgrund des verhängten Embargos gibt es bisher weder eine öffentlich bekannte CVE-Nummer, noch sonderlich viele bestätigte Informationen und / oder technische Details. Das macht eine akkurate Einschätzung der Gefährdungslage herausfordernd, um es diplomatisch zu formulieren.</p>
<p class="block">Was jedoch bekannt ist: Betroffen ist OpenSSL in den Versionen 3.0.0 bis 3.0.6, die morgen veröffentlichte Version 3.0.7 enthält die Behebung der Schwachstelle. Und die Information hilft zumindest dabei das Ausmaß der betroffenen Systeme besser einschätzen zu können.</p>
<p class="block">Im Gegensatz zu OpenSSL in den Versionen 1.x.x ist Version 3.x.x deutlich weniger verbreitet. Viele Linuxdistributionen (darunter Systeme, die aufgrund ihrer langen Supportzeiträume im Serverbereich zum Einsatz kommen) setzen noch auf ältere Versionen der Bibliothek. Das sollte die Menge an verwundbaren Systemen drastisch einschränken. Die ersten Untersuchungen, die durch Mitarbeiter:innen eines IT-Dienstleisters <a href="https://www.wiz.io/blog/critical-openssl-vulnerability-everything-you-need-to-know" target="_blank">vorgenommen wurden</a>, bestätigen diese Vermutung:</p>
<blockquote>
<p class="block">To assess the potential impact of the vulnerability, we analyzed hundreds of cloud environments from all major CSPs (AWS, GCP, Azure, OCI, and Alibaba Cloud) that contained millions of workloads. We found that over 75% of organizations have at least one impacted instance in their environment. Fortunately, only 1.5% of OpenSSL instances are impacted versions, whereas 98.5% are older, unaffected versions.</p>
</blockquote>
<p class="block">Dennoch, davon ausgehend, dass die Entwickler:innen von OpenSSL sich nicht zum Spaß für diese Einschätzung entschieden haben: Für Systeme die auf eine verwundbare Version setzen werden die Auswirkungen wohl ernst sein.</p>
<hr />
<p>Mir ist klar, dass "Habt Angst!" nicht unbedingt ein idealer Ratschlag ist. Das ist auch nicht die Botschaft, die diese Zeilen vermitteln sollen. Aufgrund der Informationspolitik der Entwickler:innen ist es aktuell leider nicht wirklich möglich zu sagen, wie sich die Situation entwickeln wird. Dennoch macht es Sinn die Schwachstelle ernst zu nehmen und Vorbereitungen zu treffen, damit die Sicherheitsaktualisierungen möglichst schnell eingespielt werden können.</p>
<ul>
<li>Betroffene Systeme identifizieren</li>
</ul>
<p>Mittels <code>sudo lsof -n | grep libssl.so.3</code> lässt sich auf den meisten Linux-Systemen herausfinden, welche laufenden Programme verwundbar sind. Unter Windows ist das Pendant zu diesem Befehl <code>dir /b/s libssl*.dll</code>. Von dort lässt sich dann feststellen welcher Service beziehungsweise welches darunterliegende Paket betroffen ist.</p>
<ul>
<li>Betroffene Systeme priorisieren</li>
</ul>
<p class="block">Verwundbare Systeme, die direkt aus dem Internet erreichbar sind, sollten als Erstes aktualisiert werden. Die weitere Priorisierung hängt von den eigenen operativen Bedürfnissen ab, aber für den Betrieb unabdingliche Systemen sollten kurz danach folgen. Auch wenn bisher nicht bekannt ist, ob es sich um eine Schwachstelle handelt, die Clients oder Server betrifft, wäre ich geneigt dem Aktualisieren von Servern / Services im Zweifelsfall die höhere Priorität einzuräumen.</p>
<ul>
<li class="block">Abwarten, präferiertes Heißgetränk trinken - Ruhe bewahren!</li>
</ul>
<p class="block">Es könnte durchaus sein, dass der morgige Tag relativ hektisch wird was Medienberichterstattung und Filterblasen in den sozialen Medien betrifft. Auch wenn die Schwachstelle sich als katastrophal herausstellen sollte: Ruhe bewahren. Alle Anderen sind genauso verwundbar wie man selbst, alle Anderen sind genauso an der Grenze zur Panik und die Angreifer:innen kochen ebenfalls nur mit Wasser. Auch dieser Sturm wird vorbeigehen, egal ob er nun im (digitalen) Ozean oder Wasserglas entsteht.</p>CERT.at2022-10-31T14:15:00ZCVE-2022-42889 - das Gute, das SchlechteCERT.at2022-10-19T15:31:12Z2022-10-19T13:37:00Z<p class="block">Einen passenden Titel für diesen Beitrag zu finden war eine unerwartete Herausforderung, weil es mehrere interessante Aspekte gibt, die bei der Betrachtung von <a href="https://nvd.nist.gov/vuln/detail/CVE-2022-42889" target="_blank">CVE-2022-42889</a> in's Auge stechen.</p>
<p class="block">Das Wichtigste jedoch vorweg, hinter der CVE-Nummer versteckt sich folgende Sicherheitslücke:</p>
<blockquote>
<p>Apache Commons Text performs variable interpolation, allowing properties to be dynamically evaluated and expanded. The standard format for interpolation is "${prefix:name}", where "prefix" is used to locate an instance of org.apache.commons.text.lookup.StringLookup that performs the interpolation. Starting with version 1.5 and continuing through 1.9, the set of default Lookup instances included interpolators that could result in arbitrary code execution or contact with remote servers.</p>
</blockquote>
<p class="block">Falls die Details dieser Schwachstelle jemandem bekannt vorkommen sollten: Zurecht, eine starke Ähnlichkeit zu CVE-2022-33980 besteht (was auch in den <a href="https://twitter.com/1ZRR4H/status/1582040744713256961" target="_blank">sozialen Medien nicht unbemerkt geblieben ist</a>).</p>
<blockquote>
<p>Apache Commons Configuration performs variable interpolation, allowing properties to be dynamically evaluated and expanded. The standard format for interpolation is "${prefix:name}", where "prefix" is used to locate an instance of org.apache.commons.configuration2.interpol.Lookup that performs the interpolation.</p>
</blockquote>
<p>Somit reiht sich diese Sicherheitslücke nahtlos ein in die Serie an Verwundbarkeiten in verschiedensten Java-Applikationen und Frameworks, die mit dem letztjährigen "Vergnügen" (im Nachhinein betrachtet bin ich sehr froh, dass ich erst mit Jänner meinen Weg - zurück - zum CERT gefunden habe) rund um die Probleme mit Log4j begonnen hat.</p>
<p>Die erste wirklich öffentliche Erwähnung fand CVE-2022-42889 letzte Woche auf der <a href="https://lists.apache.org/thread/n2bd4vdsgkqh2tm14l1wyc3jyol7s1om" target="_blank">Mailingliste</a> des Apache Projektes, bevor die Schwachstelle dann diesen Montag auf <a href="https://twitter.com/GossiTheDog/status/1581973655453433856" target="_blank">Twitter</a> und Konsorten rasch massiv an Aufmerksamkeit gewonnen hat, auch weil ein PoC bereits öffentlich <a href="https://github.com/naumanshah03/apache-commons-text-rce" target="_blank">verfügbar war und ist</a>.</p>
<p>Initial war das Bekanntwerden der Sicherheitslücke durchaus besorgniserregend, "Remote Code Execution durch willkürlichen Input in einer verbreiteten Java-Bibliothek" ist gerne ein Rezept für schlaflose Nächte. Vergleiche zu Log4Shell wurden rasch gezogen, und vor allem initial gerne unreflektiert akzeptiert und verbreitet.</p>
<p>Glücklicherweise hat die Community inzwischen leider (.. eine wunderbare Verkettung von Worten) durchaus etwas Erfahrung mit dieser Art von Schwachstellen, weswegen schnell Stimmen laut wurden, welche die Vergleiche in Frage gestellt haben.</p>
<p>Ein <a href="https://www.rapid7.com/blog/post/2022/10/17/cve-2022-42889-keep-calm-and-stop-saying-4shell/" target="_blank">Blogpost</a> des Unternehmens Rapid7, den Entwicklern von Metasploit, fasst die Situation relativ gut zusammen. Kurz gesagt ist es, im Gegensatz zu Log4j, vergleichsweise unwahrscheinlich, dass Projekte die verwundbare Komponente nutzen um ungefilterte, potentiell bösartige Daten zu verarbeiten. Die Autoren dieses Posts ziehen Vergleiche zu <a href="https://nvd.nist.gov/vuln/detail/cve-2022-22965" target="_blank">CVE-2022-22965</a>, einer weiteren ähnlichen Schwachstelle in einem Java-Framework aus diesem Jahr: Die Ausnutzung ist nicht so trivial, wie sie auf den ersten Blick erscheinen mag, in der Praxis gibt es hier einiges an Einschränkungen.</p>
<p>Ein weiterer bitterer, aber dennoch relevanter <a href="https://twitter.com/GossiTheDog/status/1582065679431499776" target="_blank">Einwand</a> aus der Community war, dass die Sicherheitslücke erst 2018 im Code entstanden sei, und die meisten Projekte wohl sowieso nicht auf so eine aktuelle Version setzen würden.</p>
<p>Meine auf Webserver-Logs basierende Telemetrie ist geographisch auf Europa und die USA limitiert, und es ist nicht immer leicht herauszufiltern, welche Schwachstelle mit seltsam anmutenden HTTP-Requests nun ausgenutzt werden soll. Aber es wirkt auf mich auch nicht so, als hätte die Veröffentlichung der Informationen zu dieser Lücke nicht zu einem merklichen Anstieg an Scans oder automatisierten Angriffsversuchen geführt. Anscheinend wird die Welt noch nicht untergehen. Zumindest nicht aufgrund von CVE-2022-42889.</p>
<hr />
<p class="block">Schlussendlich gibt es in meinen Augen zwei "lessons identified":</p>
<ul>
<li class="block">Auch wenn eine gewisse Effekthascherei wohl ihren Platz haben kann, wir täten alle gut daran, reisserische Berichte über neue Sicherheitslücken mit potentiell gravierenden Auswirkungen kritisch zu betrachten.</li>
<li class="block">Auch wenn die praktischen Auswirkungen diesmal nicht ganz so katastrophal waren, der Strom an Schwachstellen, welche "Log4" ähneln, reisst nicht ab. Das ist ein Indiz dafür, dass wir hier ein grundlegendes, strukturelles Problem haben. Ich kann nicht sagen, was genau das Problem ist. Es könnten Designprobleme sein, es könnten Qualitätsprobleme im Code sein, es könnte mangelnde Qualitätssicherung sein - oder etwas gänzlich Anderes. Aber die Tatsache, dass wir uns bei kritischen Komponenten moderner Computernetzwerke oftmals auf motivierte Einzelpersonen verlassen um Sicherheitslücken zu finden (anstatt, beispielsweise, konzertierter Maßnahmen durch Projekte oder Hersteller selbst), kann langfristig nichts Gutes verheissen.</li>
</ul>
<p class="block">Beschäftigen wird uns diese Schwachstelle, auch wenn es nicht zu massenhafter Ausnutzung kommen sollte, wohl dennoch noch eine Weile. <a href="https://twitter.com/DFNCERT/status/1582677071343808512?s=20&t=wzl_i0jhkAWj9zMWC1lUtA" target="_blank">Laut den Kollegen vom DFN-CERT</a> ist Apache Commons Text eine Abhängigkeit für über 20.000 Repositories auf Github, was für meine Kollegen in der Medienbeobachtung wohl eine Vielzahl von Advisories mit sich bringen dürfte.</p>
<p class="block">Oh, und natürlich gilt das obligatorische Mantra von CERT.at auch im Fall dieser Sicherheitslücke:</p>
<blockquote>
<p>Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen.</p>
</blockquote>
<p>Schlaflose Patchnächte sind aber nicht notwendig. Nachdem sich das Jahresende nähert hoffe ich doch, dass es Budgetfragen sind, die dem geneigten Leser den Schlaf rauben - so wie sich das für diese Jahreszeit gehört.</p>CERT.at2022-10-19T13:37:00ZShodan Verified Vulnerabilities – Statistiken zu Schwachstellen in Österreich (Updated)CERT.at2023-03-13T14:17:00Z2022-10-13T14:15:00Z<p class="block">Wir verarbeiten bereits seit einiger Zeit den Stream der Suchmaschine <a title="https://www.shodan.io/" href="https://www.shodan.io/">shodan.io</a>, der sämtliche Daten Shodans für Österreich enthält. Dieser hat sich schon bei vielen unserer Aussendungen als extrem hilfreich erwiesen, um Schwachstellen zu identifizieren und Betroffene möglichst zeitnah zu informieren.</p>
<p class="block">Seit einiger Zeit zeigt Shodan auch eine Liste von Schwachstellen an, für die die gescannten Geräte verwundbar sind. Einige davon werden aufgrund von Metadaten wie gefundenen Versionsnummern ermittelt, andere durch sicherere Methoden (Details finden sich z.B. in <a title="https://twitter.com/shodanhq/status/1216784411947126784" href="https://twitter.com/shodanhq/status/1216784411947126784">diesem Twitter-Thread</a>). Wir haben dementsprechend ein kleines Script gebastelt, dass uns eine Zusammenfassung der "Verified Vulnerabilities" erstellt und diese in eine Grafik im SVG-Format umwandelt. Mit Stand 2020-09-22 sieht das Ergebnis folgendermaßen aus:</p>
<p class="block"><img src="https://cert.at/media/files/news/blog/20200922/2020-09-22.svg" alt="Verified Vulnerabilities nach Shodan 2020-09-22" width="80%" /></p>
<p class="block">Das ist aktuell noch Work-in-Progress, geplant ist folgendes:</p>
<ul>
<li class="block">Monatliche Updates unter <a href="https://cert.at/de/meldungen/aktuelles/">https://cert.at/de/meldungen/aktuelles/</a> (done.)</li>
<li class="block">Jeweils kurze Vergleiche mit dem Vormonat und ggf. Referenzen zu Artikeln, die uns in der Medienbeobachtung dazu aufgefallen sind (done.)</li>
<li class="block">Potentiell: Erweiterung der Grafiken sodass die Schwachstellenbezeichnungen darin zu Links werden, um schnell zu einer Beschreibung des Problems zu kommen</li>
</ul>
<p class="block">Über Feedback zu diesem Plan würden wir uns freuen, wie immer an <a href="mailto:team@cert.at">team@cert.at</a>.</p>
<h2 id="liste-der-schwachstellen" class="block">Liste der Schwachstellen (wird bei "Neuzugängen" aktualisiert)</h2>
<table style="height: 365px; width: 90%; background-color: #ebebeb; margin-left: auto; margin-right: auto;" border="1px" cellspacing="10">
<tbody>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2013-1899</td>
<td style="width: 831.983px; height: 19px;">Argument Injection Schwachstelle in PostgreSQL 9.2.x < 9.2.4, 9.1.x < 9.1.9 und 9.0.x < 9.0.13</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2013-1899" href="https://nvd.nist.gov/vuln/detail/CVE-2013-1899">NIST NVD</a>, <a title="https://www.postgresql.org/support/security/faq/2013-04-04/" href="https://www.postgresql.org/support/security/faq/2013-04-04/">PostgreSQL Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2014-0160</td>
<td style="width: 831.983px; height: 19px;"> Heartbleed Schwachstelle in OpenSSL 1.0.1 vor 1.0.1g</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2014-0160" href="https://nvd.nist.gov/vuln/detail/CVE-2014-0160">NIST NVD</a>, <a title="https://www.cert.at/de/warnungen/2014/4/warnungen-20140408" href="https://www.cert.at/de/warnungen/2014/4/warnungen-20140408">CERT.at Warnung</a>, <a title="https://us-cert.cisa.gov/ncas/alerts/TA14-098A" href="https://us-cert.cisa.gov/ncas/alerts/TA14-098A">CISA Alert TA14-098A</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2015-0204</td>
<td style="width: 831.983px; height: 19px;"> FREAK Schwachstelle in OpenSSL vor 0.9.8zd, 1.0.0 vor 1.0.0p und 1.0.1 vor 1.0.1k </td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2015-0204" href="https://nvd.nist.gov/vuln/detail/CVE-2015-0204">NIST NVD</a>, <a title="https://www.cert.at/de/blog/2015/3/blog-20150306175713-1442" href="https://www.cert.at/de/blog/2015/3/blog-20150306175713-1442">CERT.at Blog</a>, <a title="https://cert.at/en/services/data/shadowserver/#ssl-freak" href="https://cert.at/en/services/data/shadowserver/#ssl-freak">Shadowserver Feed</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2015-1635</td>
<td style="width: 831.983px; height: 19px;"> Potentielle RCE Schwachstelle in Microsoft Windows 7 SP1, Windows Server 2008 R2 SP1, Windows 8, Windows 8.1 und Windows Server 2012 Gold und R2</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2015-1635" href="https://nvd.nist.gov/vuln/detail/CVE-2015-1635">NIST NVD</a>, <a title="https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2015/ms15-034" href="https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2015/ms15-034">Microsoft Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2015-2080</td>
<td style="width: 831.983px; height: 19px;">Auslesen potentiell sensitiver Informationen in Eclipse Jetty before 9.2.9.v20150224 über das Netzwerk und ohne Authentifizierung</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2015-2080" href="https://nvd.nist.gov/vuln/detail/CVE-2015-2080">NIST NVD</a>, <a title="https://www.eclipse.org//lists/jetty-announce/msg00075.html" href="https://www.eclipse.org//lists/jetty-announce/msg00075.html">Eclipse Mail-Thread</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2015-4000</td>
<td style="width: 831.983px; height: 19px;"> Logjam Schwachstelle in TLS <= 1.2 wenn eine DHE_EXPORT Ciphersuite am Server aber nicht am Client aktiviert ist</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2015-4000" href="https://nvd.nist.gov/vuln/detail/CVE-2015-4000">NIST NVD</a>, <a title="https://cert.at/de/meldungen/blog/blog-20150521111403-1485" href="https://cert.at/de/meldungen/blog/blog-20150521111403-1485">CERT.at Blogpost</a>, <a title="https://www.openssl.org/news/secadv/20150611.txt" href="https://www.openssl.org/news/secadv/20150611.txt">OpenSSL Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2016-9244</td>
<td style="width: 831.983px; height: 19px;"> Potentielles Auslesen sensitiver Daten im BIG-IP Virtual Server</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2016-9244" href="https://nvd.nist.gov/vuln/detail/CVE-2016-9244">NIST NVD</a>, <a title="https://support.f5.com/csp/article/K05121675" href="https://support.f5.com/csp/article/K05121675">F5 Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2017-7269</td>
<td style="width: 831.983px; height: 19px;"> Remote Code Execution in Microsoft IIS 6.0 in Microsoft Windows Server 2003 R2</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2017-7269" href="https://nvd.nist.gov/vuln/detail/CVE-2017-7269">NIST NVD</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2019-0708</td>
<td style="width: 831.983px; height: 19px;"> Remote Code Execution in RDP</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2019-0708" href="https://nvd.nist.gov/vuln/detail/CVE-2019-0708">NIST NVD</a>, <a title="https://www.cert.at/de/warnungen/2019/5/warnungen-20190516" href="https://www.cert.at/de/warnungen/2019/5/warnungen-20190516">CERT.at Warnung</a>, <a title="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708" href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708">Microsoft Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2019-11510</td>
<td style="width: 831.983px; height: 19px;"> Auslesen beliebiger Dateien über das Netzwerk und ohne Authentifizierung in Pulse Secure Pulse Connect Secure (PCS) 8.2 vor 8.2R12.1, 8.3 vor 8.3R7.1 und 9.0 vor 9.0R3.4</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2019-11510" href="https://nvd.nist.gov/vuln/detail/CVE-2019-11510">NIST NVD</a>, <a title="https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44101/" href="https://kb.pulsesecure.net/articles/Pulse_Security_Advisories/SA44101/">Pulse Secure Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2019-1652</td>
<td style="width: 831.983px; height: 19px;"> Authenticated RCE auf Cisco Small Business RV320 und RV325 Dual Gigabit WAN VPN Routern</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2019-1652" href="https://nvd.nist.gov/vuln/detail/CVE-2019-1652">NIST NVD</a>, <a title="https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190123-rv-inject" href="https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190123-rv-inject">Cisco Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2019-1653</td>
<td style="width: 831.983px; height: 19px;"> Auslesen sensitiver Informationen aus Cisco Small Business RV320 und RV325 Dual Gigabit WAN VPN Routern</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2019-1653" href="https://nvd.nist.gov/vuln/detail/CVE-2019-1653">NIST NVD</a>, <a title="https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190123-rv-info" href="https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190123-rv-info">Cisco Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2019-19781</td>
<td style="width: 831.983px; height: 19px;"> "Shitrix", eine Schwachstelle in Citrix Application Delivery Controller (ADC) und Gateway 10.5, 11.1, 12.0, 12.1, und 13.0, die die vollständige Übernahme des Geräts ermöglicht</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2019-19781" href="https://nvd.nist.gov/vuln/detail/CVE-2019-19781">NIST NVD</a>, <a title="https://cert.at/de/blog/2020/1/citrix-cve-2019-19781-aktiv-ausgenutzt" href="https://cert.at/de/blog/2020/1/citrix-cve-2019-19781-aktiv-ausgenutzt">CERT.at Blogpost</a>, <a title="https://support.citrix.com/article/CTX267027" href="https://support.citrix.com/article/CTX267027">Citrix Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2020-5902</td>
<td style="width: 831.983px; height: 19px;"> Eine unauthenticated RCE im Traffic Management User Interface von F5s BIG IP Produkten</td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2020-5902" href="https://nvd.nist.gov/vuln/detail/CVE-2020-5902">NIST NVD</a>, <a title="https://support.f5.com/csp/article/K52145254" href="https://support.f5.com/csp/article/K52145254">F5 Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">CVE-2020-0796</td>
<td style="width: 831.983px; height: 19px;"> Remote Code Execution durch eine Schwachstelle in Microsoft Server Message Block 3.1.1 (SMBv3) </td>
<td style="width: 343.333px; height: 19px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2020-0796" href="https://nvd.nist.gov/vuln/detail/CVE-2020-0796">NIST NVD</a>, <a title="https://cert.at/de/warnungen/2020/3/kritische-sicherheitslucke-in-microsoft-smbv3-workarounds-verfugbar" href="https://cert.at/de/warnungen/2020/3/kritische-sicherheitslucke-in-microsoft-smbv3-workarounds-verfugbar">CERT.at Warnung</a>, <a title="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796" href="https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-0796">Microsoft Advisory</a></td>
</tr>
<tr style="height: 33px;">
<td style="height: 33px;">CVE-2020-11651</td>
<td style="height: 33px;"> Fehlerhafte Überprüfung von Methoden-Aufrufen im SaltStack, was potentiell das Auslesen von Account-Tokens vom Salt Master bzw. RCE ohne Authentifizierung auf Salt Minions ermöglicht.</td>
<td style="height: 33px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2020-11651" href="https://nvd.nist.gov/vuln/detail/CVE-2020-11651"> NIST NVD</a>, <a title="https://docs.saltstack.com/en/latest/topics/releases/2019.2.4.html" href="https://docs.saltstack.com/en/latest/topics/releases/2019.2.4.html">SaltStack Advisory</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2020-11652</td>
<td style="height: 16px;"> Fehlerhafte Pfad-Bereinigung, die authentifizierten NutzerInnen ermöglicht, auf beliebige Dateien zuzugreifen.</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2020-11652" href="https://nvd.nist.gov/vuln/detail/CVE-2020-11652">NIST NVD</a>, <a title="https://docs.saltstack.com/en/latest/topics/releases/2019.2.4.html" href="https://docs.saltstack.com/en/latest/topics/releases/2019.2.4.html">SaltStack Advisory</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-26855</td>
<td style="height: 16px;">Microsoft Exchange Server Remote Code Execution Vulnerability</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-26855" href="https://nvd.nist.gov/vuln/detail/CVE-2021-26855">NIST NVD</a>, <a title="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/" href="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/">Microsoft Advisory</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-26857</td>
<td style="height: 16px;">Microsoft Exchange Server Remote Code Execution Vulnerability</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-26857" href="https://nvd.nist.gov/vuln/detail/CVE-2021-26857">NIST NVD</a>, <a title="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/" href="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/">Microsoft Advisory</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-26858</td>
<td style="height: 16px;">Microsoft Exchange Server Remote Code Execution Vulnerability</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-26858" href="https://nvd.nist.gov/vuln/detail/CVE-2021-26858">NIST NVD</a>, <a title="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/" href="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/">Microsoft Advisory</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-27065</td>
<td style="height: 16px;">Microsoft Exchange Server Remote Code Execution Vulnerability</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-27065" href="https://nvd.nist.gov/vuln/detail/CVE-2021-27065">NIST NVD</a>, <a title="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/" href="https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/">Microsoft Advisory</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-31206</td>
<td style="height: 16px;">Microsoft Exchange Server Remote Code Execution Vulnerability</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-31206" href="https://nvd.nist.gov/vuln/detail/CVE-2021-31206">NIST NVD</a>, <a title="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-31206" href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-31206">Microsoft Advisory</a>, <a title="https://www.zerodayinitiative.com/advisories/ZDI-21-826/" href="https://www.zerodayinitiative.com/advisories/ZDI-21-826/">ZDI Advisory</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-31207</td>
<td style="height: 16px;">Microsoft Exchange Server pre-auth path confusion (Teil von ProxyShell)</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-31207" href="https://nvd.nist.gov/vuln/detail/CVE-2021-31207">NIST NVD</a>, <a title="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-31207" href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-31207">Microsoft Advisory</a>, <a title="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell" href="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell">ZDI Blogpost</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-34473</td>
<td style="height: 16px;">Microsoft Exchange Server Privilegieneskalation im PowerShell Backend (Teil von ProxyShell)</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-34473" href="https://nvd.nist.gov/vuln/detail/CVE-2021-34473">NIST NVD</a>, <a title="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-34473" href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-34473">Microsoft Advisory</a>, <a title="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell" href="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell">ZDI Blogpost</a></td>
</tr>
<tr style="height: 16px;">
<td style="height: 16px;">CVE-2021-34523</td>
<td style="height: 16px;">Microsoft Exchange Server Erstellung beliebiger Dateien (Teil von ProxyShell)</td>
<td style="height: 16px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-34523" href="https://nvd.nist.gov/vuln/detail/CVE-2021-34523">NIST NVD</a>, <a title="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-34523" href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-34523">Microsoft Advisory</a>, <a title="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell" href="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell">ZDI Blogpost</a></td>
</tr>
<tr style="height: 19.6167px;">
<td style="width: 155.683px; height: 19.6167px;">CVE-2021-43798</td>
<td style="width: 831.983px; height: 19.6167px;">Grafana Path Traversal Vulnerability</td>
<td style="width: 343.333px; height: 19.6167px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2021-43798" href="https://nvd.nist.gov/vuln/detail/CVE-2021-43798">NIST NVD</a>, <a title="https://grafana.com/blog/2021/12/08/an-update-on-0day-cve-2021-43798-grafana-directory-traversal/" href="https://grafana.com/blog/2021/12/08/an-update-on-0day-cve-2021-43798-grafana-directory-traversal/">Grafana Blogpost</a></td>
</tr>
<tr style="height: 19.6167px;">
<td style="width: 155.683px; height: 19.6167px;">CVE-2022-32548</td>
<td style="width: 831.983px; height: 19.6167px;">DrayTek Authentication Bypass Vulnerability</td>
<td style="width: 343.333px; height: 19.6167px;"><a title="https://nvd.nist.gov/vuln/detail/CVE-2022-32548" href="https://nvd.nist.gov/vuln/detail/CVE-2022-32548" target="_blank">NIST NVD</a>, <a title="https://www.draytek.com/about/security-advisory/draytek-router-unauthenticated-remote-code-execution-vulnerability-(cve-2022-32548)/" href="https://www.draytek.com/about/security-advisory/draytek-router-unauthenticated-remote-code-execution-vulnerability-(cve-2022-32548)/" target="_blank">DrayTek Advisory</a></td>
</tr>
<tr style="height: 19.6167px;">
<td style="width: 155.683px; height: 19.6167px;">CVE-2022-36804</td>
<td style="width: 831.983px; height: 19.6167px;">Command Injection Schwachstelle in Atlassian Bitbucket Server und Data Center</td>
<td style="width: 343.333px; height: 19.6167px;"><a title="https://nvd.nist.gov/vuln/detail/cve-2022-36804" href="https://nvd.nist.gov/vuln/detail/cve-2022-36804" target="_blank">NIST NVD</a>, <a title="https://confluence.atlassian.com/bitbucketserver/bitbucket-server-and-data-center-advisory-2022-08-24-1155489835.html" href="https://confluence.atlassian.com/bitbucketserver/bitbucket-server-and-data-center-advisory-2022-08-24-1155489835.html" target="_blank">Atlassian Advisory</a></td>
</tr>
<tr style="height: 19px;">
<td style="width: 155.683px; height: 19px;">MS15-034</td>
<td style="width: 831.983px; height: 19px;"> Gleiches Microsoft Advisory wie für CVE-2015-1635</td>
<td style="width: 343.333px; height: 19px;"><a title="https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2015/ms15-034" href="https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2015/ms15-034">Microsoft Advisory</a></td>
</tr>
<tr style="height: 20px;">
<td style="width: 155.683px; height: 20px;">MS17-010</td>
<td style="width: 831.983px; height: 20px;">"Eternal Blue", eine Schwachstelle in Microsoft Server Message Block 1.0 (SMBv1) Server, die u.a. bei WannaCry ausgenutzt wurde</td>
<td style="width: 343.333px; height: 20px;"><a title="https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2017/ms17-010" href="https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2017/ms17-010">Microsoft Advisory,</a> <a title="https://cert.at/de/warnungen/2017/5/warnungen-20170513" href="https://cert.at/de/warnungen/2017/5/warnungen-20170513">CERT.at Warnung zu WannaCry</a></td>
</tr>
</tbody>
</table>CERT.at2022-10-13T14:15:00ZEin guter Tag für Freund:innen von Adobe Software und gepflegtem PatchenCERT.at2022-10-12T12:18:07Z2022-10-12T12:15:00Z<p class="block">Da kann man sich nicht beschweren: nicht nur eine <a title="Link zum CERT.at-Warning bzgl. Adobe Commerce und Magento Open Source" href="https://cert.at/de/warnungen/2022/10/kritische-sicherheitslucke-in-magento-open-source-und-adobe-commerce-updates-verfugbar" target="_blank">kritische Lücke in Adobe Commerce und Magento Open Source</a> (CVSS 10.0 - Highscore-verdächtig), sondern auch gleich <a title="Link zum Adobe Security Bulletin zu ColdFusion" href="https://helpx.adobe.com/security/products/coldfusion/apsb22-44.html" target="_blank">deren mehrere in Adobe ColdFusion</a> (unter Anderem 4x mit CVSS 9.8 und 1x mit 8.1).</p>
<p class="block">Nutzer:innen von Adobe Acrobat/Acrobat Reader <a title="Link zum Adobe Security Bulletin zu Acrobat/Acrobat Reader" href="https://helpx.adobe.com/security/products/acrobat/apsb22-46.html" target="_blank">kommen ebenfalls nicht zu kurz</a>, auch wenn man dort dank Auto-Updates vielleicht nicht selbst so viel Spass mit dem Patchen hat.</p>
<p class="block">Und auch wenn ich nicht weiß, was (eine) Adobe Dimension ist: Admins haben dort <a title="Link zu Adobe Security Bulletin zu Adobe Dimension" href="https://helpx.adobe.com/security/products/dimension/apsb22-57.html" target="_blank">4x CVSS 7.8 - Freude</a>.</p>
<p class="block"> </p>
<p class="block">Aber Adobe ist hier nicht allein, Microsoft matcht den CVSS von 10.0 direkt mit einem <a title="Link zu Microsoft Artikel bzgl. Azure Arc-enabled Kubernetes Cluster" href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-37968" target="_blank">Bug in Azure Arc-enabled Kubernetes Cluster</a> und schiebt auch noch gleich 1x CVSS 7.8 mit <a title="Link zu Microsoft Artikel bzgl. Privilege Elevation in Windows COM+ Event System Service" href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-41033" target="_blank">Privilege Elevation in Windows COM+ Event System Service</a> nach, während Admins von Microsoft Exchange weiter Wetten abschliessen wie lange <a title="Link zum CERT.at Warning zu Microsoft Exchange" href="https://cert.at/de/warnungen/2022/10/0-day-exploit-remote-code-execution-in-microsoft-exchange-on-premise-workaround-verfugbar" target="_blank">die letzte Mitigation für die aktuellen Probleme diesmal hält</a> - mit einem CVSS von 8.8 ist man da jedenfalls halbwegs weit vorne dabei.</p>
<p class="block"> Und auch sonst ist der <a title="Link zu heise-Artikel zum Microsoft Patch Tuesday" href="https://www.heise.de/news/Patchday-Attacken-auf-Windows-und-immer-noch-kein-Exchange-Patch-in-Sicht-7305736.html" target="_blank">Patch Tuesday nicht langweilig</a>.</p>CERT.at2022-10-12T12:15:00ZUnd täglich grüßt die Microsoft Exchange On-Prem SchwachstelleCERT.at2022-10-03T14:54:55Z2022-10-03T13:59:00Z<p class="block">Letztes Jahr schon führten diverse Microsoft Exchange 0-day Schwachstellen - ProxyLogon, ProxyOracle und ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) - zu einigermaßen chaotischen Zuständen. Dies kann zum Teil auf die späte Reaktion des Herstellers beziehungsweise die verwirrenden, zum Teil falschen Anleitungen für eine erfolgreiche Mitigation der Schwachstelle zurückgeführt werden. Zum Zeitpunkt der Veröffentlichung des Patches waren 2021 bereits eine große Anzahl an Exchange-Server weltweit kompromittiert.<br />Ende letzter Woche wurde nun eine neue 0-day Schwachstelle - ProxyNotShell (CVE-2022-40140, CVE-2022-41082) getauft - in Exchange bekannt, die zwar im Gegensatz zu ProxyShell - laut offiziellen Informationen - nur authentifiziert eine Remote-Code-Execution (RCE) zulässt, aber dennoch nicht zu unterschätzen ist, da bereits ein Standardbenutzer reicht, um das komplette System zu übernehmen. Diese Schwachstelle wird auch bereits - wenn auch, laut Microsoft nur begrenzt - aktiv ausgenutzt.<br />Nach Veröffentlichung des initialen Blog-Beitrags zur Schwachstelle und der Meldung an die Zero Day Initiative, hat der Hersteller dieses Mal zwar flott mit Anleitungen für eine Mitigation reagiert, jedoch hat sich gezeigt, dass diese wieder zum Teil falsch beziehungsweise unzureichend sind.</p>
<p class="block">Ohne hier jetzt genau ins Detail zu gehen und die Anzahl der vielleicht in naher Zukunft kompromittierten Systeme zu kennen, soll hier und jetzt die Zeit sein, erneut auf folgendes hinzuweisen ...</p>
<p class="block"><strong>Ein On-Prem Exchange-Server ist nur dann ein sicherer oder zumindest halbwegs sicherer Exchange-Server, wenn seine Webinterfaces (Outlook Web Access, Exchange Web Services, etc) ausschließlich über private, gesicherte Verbindungen (zum Beispiel VPN) erreichbar sind.</strong></p>CERT.at2022-10-03T13:59:00ZMOTW (Mark of the Web) - Retter in der Not?CERT.at2022-08-26T19:39:39Z2022-08-24T17:42:00Z<h2 class="block">Einführung - Die Mutter aller Probleme</h2>
<p class="block">In vielen Fällen sind infizierte Computer auf Dateien zurückzuführen, die ursprünglich aus dem Internet <em>stammen</em> und per Webbrowser oder E-Mail Client durch bewusstes Herunterladen/Speichern ihren Weg auf Erstere gefunden haben. Dies gilt gleichermaßen für ausführbare Dateien (Portable Executables oder Scripts) als auch <em>normale</em> Dateien wie Dokumente (.doc, .pdf, ...). Letztere sind zwar nicht direkt <em>ausführbar</em>, können aber als <em>Einfädler</em> für maliziöse Aktivitäten missbraucht werden.</p>
<p class="block">Um diesem Szenario entsprechend Rechnung zu tragen und Computer dagegen besser schützen zu können, bräuchte es als Grundlage eine Art Markierung für jene aus dem Internet stammende Dateien, so dass diese in weiterer Folge vom Betriebssystem und von Applikationen automatisch mit größerer Vorsicht behandelt werden könnten. So die Theorie.</p>
<h2 class="block">Umsetzung - Die Geburt von MOTW</h2>
<p class="block">Die Umsetzung dieses logischen, einfach nachzuvollziehenden Ansatzes, stellt jedoch ein relativ komplexes Problem dar. Zum einen müssen die besagten Dateien jene Markierung erhalten, müssen aber auch gleichermaßen voll funktionstüchtig, also inhaltlich unangetastet, bleiben. Darüber hinaus muss die Markierung der Dateien kopier- und verschiebeoperationsresistent sein.</p>
<p class="block">Dieser einem Spagat gleichenden Aufgabenstellung hat sich vor vielen Jahren Microsoft angenommen und die Technologie MOTW, ein Akronym für "Mark of the Web", entwickelt. Grundlage deren Lösungsansatzes ist es, die Fähigkeit des Windows Standard-Filesystems NTFS, neben dem Hauptdatenstrom einer Datei auch beliebig viele Nebenströme (Alternative Datenströme, ADS genannt) zu dieser speichern/führen zu können, für die besagte Markierung zu nützen. Dadurch bleibt der originale Inhalt der Datei, also der Hauptdatenstrom, zum Einen unangetastet, und zum Anderen wird der Alternative Datenstrom, das MOTW, bei Fileoperationen mitberücksichtigt. Das heißt, wird die betreffende Datei kopiert oder verschoben, so wird das MOTW mitkopiert, beziehungsweise mitverschoben.</p>
<p class="block">Die Markierung, die damit technisch zufriedenstellend umsetzbar war, musste aber auch noch von <em>Jemandem</em> oder <em>Etwas</em> gesetzt werden. Für Microsoft war damals der Internet Explorer die logische Wahl und so wurde dieser entsprechend um die Funktionalität, den (alternativen) MOTW Datenstrom an Downloads automatisch anzuhängen, erweitert.</p>
<p class="block">Damit war die Basis für die gewünschte Sonderbehandlungsmöglichkeit für aus dem Internet heruntergeladene Dateien gelegt. Die damalige Implementierung abschließend, und um derartige Dateien auch noch verarbeiten zu können, wurde in Windows eine Sicherheitshürde in Form einer Warnung/Freigabeabfrage bei der Ausführung solcher Dateien eingeführt.</p>
<h2 class="block">MOTW - Eine Frage der Disziplin</h2>
<p class="block">MOTW ist ein technisch durchdachter, konsistenter und funktioneller Ansatz, jedoch ist auch bei diesem wieder die Disziplin aller <em>Beteiligten</em> gefragt. Letzten Endes liegt es am Anwender zu entscheiden, ob die beim Öffnen/Ausführen einer betreffenden Datei angezeigte Warnung übergangen wird oder nicht. Und in den meisten Fällen wird Ersteres wohl auch legitim sein.</p>
<p class="block">Disziplin ist aber in dieser Sache nicht nur vom Anwender gefragt - auch die Entwickler der (anderen) Webbrowser (und E-Mail Clients) sowie der, die markierten Dateien verarbeitenden Applikationen, müssen dieses Lösungskonzept entsprechend mittragen.</p>
<h2 class="block">MOTW - Status Quo</h2>
<p class="block">Heutzutage wird das Schreiben der MOTW Markierung von den gängigsten Web Browsern unterstützt. Was E-Mail Clients anbelangt, gibt es diesbezüglich aber leider Nachholbedarf. In allen Fällen gilt aber, dass der Support von MOTW von der jeweiligen Version der Software/Applikation abhängig ist. Ist man sich unsicher bezüglich der selbst genutzten Software, und die Recherche im Internet ist diesbezüglich in den meisten Fällen wenig aussagekräftig/fruchtbringend, empfiehlt sich, es einfach auszuprobieren, also, eine Datei runterzuladen bzw. ein Attachment zu speichern. Danach muss man nur noch die Dateien auf die MOTW Markierung überprüfen.</p>
<h2 class="block">MOTW, zeig Dich!</h2>
<p class="block">Will man herausfinden, ob eine Datei MOTW-markiert ist, so gibt es mehrere Methoden - hier eine Auswahl der einfachsten:</p>
<ol>
<li class="block">Die Eigenschaften (Allgemeiner Reiter) der betreffenden Datei im Windows Explorer (erreichbar durch dessen Kontextmenü) enthalten einen sich mit der Abbildung deckenden oder vergleichbaren Spezialbereich.<br /><br /><img src="https://cert.at/media/files/news/blog/motw-mark-of-the-web-retter-in-der-not/files/23-08-2022_18-30-09.png" alt="" width="619" height="802" /><br /><br /></li>
<li class="block">Über ein Konsolen-Fenster (cmd.exe) kann man über den Befehl <code>dir /r</code> die alternativen Datenströme der im aktuellen Verzeichnis enthaltenen Dateien anzeigen lassen, und damit auch die MOTW Markierung derer ... siehe Abbildung.<br /><br /><img src="https://cert.at/media/files/news/blog/motw-mark-of-the-web-retter-in-der-not/files/23-08-2022_18-44-53.png" alt="" width="779" height="301" /></li>
</ol>
<h2 class="block">MOTW - Status Quo, die 2te</h2>
<p class="block">Abseits der MOTW-schreibenden Software ist jene, die das MOTW verarbeiten und interpretieren kann, natürlich mindestens genauso wichtig. Hier zeigt sich aber, dass das diesbezügliche Feld ein sehr durchwachsenes ist. Und das fängt schon bei Windows selbst an. Während der Start einer MOTW-markierten ausführbaren Datei über den Windows Explorer über mehrere Schritte im Hintergrund verifiziert und durch einen Dialog blockiert wird (siehe weiter unten), lässt sich selbige Datei über ein Konsolen-Fenster (cmd.exe) ohne Einschränkung starten. Für allgemeine Anwendungssoftware/-applikationen verhält es sich ähnlich wie weiter oben schon erwähnt: Recherche im Internet ist diesbezüglich in den meisten Fällen wenig aussagekräftig/fruchtbringend, eine (erschöpfende) Liste an unterstützenden Applikationen ein Wunschtraum. Es empfiehlt sich demnach auch an dieser Stelle, es einfach auszuprobieren, also, MOTW-markierte Dateien unterschiedlicher Formate/Extensions mit den präferierten Applikationen zu öffnen und auf deren Verhalten zu achten.</p>
<h2 class="block">Vorzeigeschüler Windows Explorer</h2>
<p class="block">Wird eine MOTW-markierte ausführbare Datei im Windows Explorer gestartet (Doppelklick, Enter-Taste), passieren folgende Schritte:</p>
<ol>
<li class="block">Überprüfung durch SmartScreen Application Reputation (Win8+) sowie aller installierter Antiviren Scanner</li>
<li class="block">Überprüfung der digitalen Signatur der Datei</li>
<li class="block">Warnung und Bestätigungsanforderung an den Benutzer durch Dialog (siehe Abbildung)<br /><br /><img src="https://cert.at/media/files/news/blog/motw-mark-of-the-web-retter-in-der-not/files/24-08-2022_16-19-27.png" alt="" width="665" height="580" /></li>
</ol>
<h2 class="block">Corner Cases als potentielle Schlupflöcher und Fallstricke</h2>
<p class="block">Abseits der teils fehlenden Disziplin und Verlässlichkeit oder generellen Unterstützungsbereitschaft der einzelnen (potentiellen) Teilnehmer im MOTW <em>Rollenspiel</em>, zeigt sich leider auch ein hohes Potential an Bypass-Szenarien. So kann es durchaus sein, dass eine MOTW Markierung <em>versehentlich</em> verloren geht.</p>
<p class="block">Dies gilt insbesondere für den Umgang mit komprimierten Archiven. Je nach verwendeter Software, nimmt diese auf die Vererbung einer etwaig gesetzten MOTW Markierung beim Entpacken eines Archives Rücksicht oder nicht. Die Windows on-board ZIP Implementierung macht es richtig, und die ausgepackten Dateien erhalten die MOTW Markierung des ursprünglichen Archives. Das allseits beliebte 7-zip hingegen hat bis zum letzten Versionsupdate im Mai/Juni 2022 (siehe auch obig erwähnte Versionsabhängigkeit) MOTW komplett ignoriert.</p>
<p class="block">Aber auch das Windows-eigene ZIP kommt schnell an seine Grenzen. Geht man den umgekehrten Weg und packt die gerade entpackten, mit der vom ursprünglichen Archiv geerbten MOTW Markierung versehenen, Dateien in ein neues Archiv, so gehen die Markierungen dabei verloren und das resultierende Archiv ist ebenfalls nicht markiert.</p>
<p class="block">Ähnliches passiert, wenn eine MOTW-markierte Datei auf/über einen Datenträger verschoben/kopiert/transferiert wird, der nicht auf NTFS formatiert ist. Die Markierung geht auf halbem Weg verloren, beziehungsweise entsteht erst gar nicht.</p>
<p class="block">Was bei genauerer Betrachtung dieser Beispiele vielleicht noch teils nachvollziehbar erscheint, verdeutlicht aber dennoch, wie <em>filigran</em> die MOTW Technologie ist. Zu viele Zahnräder müssen erfolgreich in einander greifen, ein Umstand, der von Angreifern natürlich bewusst ausgenützt werden kann.</p>
<h2 class="block">Game Over, MOTW!</h2>
<p class="block">Dass Angreifer jene gerade beschriebene Schwäche von MOTW nicht nur ausnützen <em>können</em>, sondern es <em>effektiv tun</em>, sei an dieser Stelle anhand eines Beispiels, das sich dem zurzeit besonders beliebten ISO Image (.iso Dateien) Ansatz bedient, skizziert.</p>
<p class="block">Worum geht's bei besagtem Ansatz? Angreifer versenden E-Mails (Spams) mit einer .iso-Datei - ein ISO Image - als Attachment. Ein ISO Image ist nichts anderes als ein virtuelles Abbild einer CD/DVD, das weitere Dateien (wie eben eine <em>echte</em> CD/DVD) enthalten kann. Der Empfänger, zumindest so das Kalkül der Angreifer, das sich leider nur allzu oft erfüllt, speichert das Attachment zur weiteren Begutachtung auf einem lokalen Datenträger oder öffnet dieses, sofern vom verwendeten E-Mail Client unterstützt, direkt (was im Hintergrund letzten Endes wiederum zu einem, wenn auch temporären, Zwischenspeichern auf dem Datenträger führt). Wird diese Datei nun <em>ausgeführt</em>, manuell über den Windows Explorer oder implizit (durch das direkte Öffnen), so wird diese virtuelle CD/DVD vollwertig verbunden (gemountet). In Abhängigkeit vom verwendeten E-Mail Client wurde beim Wegschreiben des Attachments auf den Datenträger eventuell auch eine MOTW Markierung gesetzt. Gehen wir mal vom Best-Case aus, das heißt, die MOTW Markierung wurde gesetzt und die Datei manuell mit dem Windows Explorer geöffnet. Unter dieser Voraussetzung wird das erwähnte Mounting nicht automatisch in Eigenregie ausgeführt, sondern der Benutzer wird zuvor noch wegen der *externen Abstammung* der Datei nach einer Bestätigung gefragt (siehe Abbildung).</p>
<p class="block"><img src="https://cert.at/media/files/news/blog/motw-mark-of-the-web-retter-in-der-not/files/26-08-2022_13-32-16.png" alt="" width="665" height="580" /></p>
<p class="block">Nehmen wir an, diese Bestätigung wurde erteilt, wie geht es nun weiter? Da das ISO Image jetzt erfolgreich gemountet wurde, wird dessen Inhalt im Windows Explorer <em>normal</em> angezeigt, das heißt, die enthaltenen Dateien, beziehungsweise nur <em>eine</em>, die dem Angreifer grundsätzlich ja schon reicht. Diese Datei kann jetzt alles sein, ein Office Dokument mit integriertem Makro oder aber auch eine direkt ausführbare Datei. Aus der Perspektiv der MOTW Thematik betrachtet, muss dieses Szenario nun nicht mehr weitergesponnen werden, es verhält sich so, als gäbe es MOTW nicht.</p>
<p class="block">Wie kommt es dazu, dass uns MOTW in diesem Fall so im Regen stehen lässt? Wie bereits zuvor einmal erwähnt, handelt es sich bei einem ISO Image um ein virtuelles Abbild einer CD/DVD. Eine CD/DVD enthält Dateien, also braucht es auch ein Filesystem, das diese Dateien verwaltet. Bei diesem Filesystem handelt es sich allerdings nicht um NTFS, was aber wiederum Voraussetzung für MOTW wäre. Die enthaltenen Dateien tanzen damit aus Sicht eines Angreifers erfolgreich aus der <em>MOTW Reihe</em>. Insofern ist diese Situation auch mit Archiven vergleichbar, die beim Entpacken eine etwaige MOTW Markierung nicht weitervererben (siehe auch weiter oben).</p>
<h2 class="block">Fazit</h2>
<p class="block">MOTW ist ein Paradebeispiel dafür, dass eine an sich geniale Idee und dessen Umsetzung dennoch (oder gerade deswegen?) an der Diversität und Disziplin aller Beteiligten scheitern kann. Dennoch sei hier unbestritten festgehalten: MOTW ist eine wichtige und wertvolle Technologie, die schon vielen Usern, gerade unter Verwendung von Mainstream Software, gröbere Probleme/eine Infektion mit Malware erspart hat. Analog zu vielen anderen Verteidigungsansätzen, legt auch diese am Ende des Tages die Latte für einen Angreifer (nur) wieder etwas höher.</p>
<h2 class="block">Quellen</h2>
<p class="block">- <a href="https://nolongerset.com/mark-of-the-web-details/">https://nolongerset.com/mark-of-the-web-details/</a><br />- <a href="https://textslashplain.com/2016/04/04/downloads-and-the-mark-of-the-web/">https://textslashplain.com/2016/04/04/downloads-and-the-mark-of-the-web/</a><br />- <a href="https://office-watch.com/2022/inside-the-office-vba-motw-changes/">https://office-watch.com/2022/inside-the-office-vba-motw-changes/</a><br />- <a href="https://blog.actorsfit.com/a?ID=01650-2b32beec-b371-45a9-9ecb-1aee69b9314c">https://blog.actorsfit.com/a?ID=01650-2b32beec-b371-45a9-9ecb-1aee69b9314c</a><br />- <a href="https://outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-teams-perspective/">https://outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-teams-perspective/</a><br />- <a href="https://www.bleepingcomputer.com/news/microsoft/7-zip-now-supports-windows-mark-of-the-web-security-feature/">https://www.bleepingcomputer.com/news/microsoft/7-zip-now-supports-windows-mark-of-the-web-security-feature/</a><br />- <a href="https://en.wikipedia.org/wiki/Optical_disc_image">https://en.wikipedia.org/wiki/Optical_disc_image</a><br />- <a href="https://malicious.link/post/2022/blocking-iso-mounting/">https://malicious.link/post/2022/blocking-iso-mounting/</a><br />- <a href="https://threatpost.com/threat-pivot-microsofts-macro/180319/">https://threatpost.com/threat-pivot-microsofts-macro/180319/</a></p>CERT.at2022-08-24T17:42:00ZSicherheitslücken - jetzt auch in deiner ApplianceCERT.at2022-08-22T16:20:29Z2022-08-22T15:00:00Z<p class="block">Die Entwickler des quelloffenen Frameworks YARA haben vor knapp zwei Wochen fast schon heimlich still und leise eine neue Version veröffentlicht, v4.2.3, welche in der medialen Berichterstattung beinahe untergegangen ist.</p>
<p class="block">Grundsätzlich ist eine neue Softwareversion zwar nichts ungewöhnliches, aber wenn sich in den <a href="https://github.com/VirusTotal/yara/releases/tag/v4.2.3" target="_blank">Patchnotes</a> folgende Zeile befindet tendiere ich doch zur leichten bis mittleren Unruhe:</p>
<blockquote>
<p class="block">BUGFIX: Fix security issue that can lead to arbitrary code execution</p>
</blockquote>
<p class="block">Bei dem Bugfix handelt es sich um <a href="https://github.com/VirusTotal/yara/commit/b77e4f45b4662af320c999d4ee559e1f3bc61226" target="_blank">eine Veränderung</a> in <a href="https://github.com/VirusTotal/yara/blob/master/libyara/exec.c" target="_blank">libyara/exec.c</a>. Ich bin so weit von der Rolle eines C-Programmierers (oder irgendeines Programmierers, was das anbelangt) weg, wie man sich nur vorstellen kann. Aber sogar ich traue mich mit relativer Gewissheit zu sagen, dass ein potentiell korrumpierter Stack in einem wichtigen Bestandteil der C/C++-API von YARA eine wirklich hässliche Sache ist.</p>
<p class="block">Auf den ersten Blick lässt sich das Problem wohl trivial lösen, wenn man die aktualisierte Version verwendet ist man auf der sicheren Seite. Das Einspielen eines Updates ist für mich als Analyst nicht unbedingt die größte aller Herausforderungen.</p>
<p class="block">Aber: YARA kommt wohl, auf die eine oder andere Art und Weise, im Großteil der Sandboxen, Antivirenlösungen und sonstigen Sicherheitsapplikationen, sowohl kommerziell als auch quelloffen, zum Einsatz. In vielen Produkten oder Lösungen ist es sogar ein integraler, tief im System verankerter Bestandteil. Das Einspielen einer neuen Version ist hier oft zeitaufwendig, manchmal komplex, und unter Umständen sogar ein Großprojekt. Was bedeutet, dass es in vielen Fällen eine lange Zeit dauern wird bis diese Sicherheitslücke geschlossen wird.</p>
<p class="block">Mir ist bewusst, dass das nicht notwendigerweise ein Weltuntergang ist. Ohne größere Teile des Quellcodes der Software ausführlich durchgearbeitet zu haben kann ich nicht vertrauenswürdig beurteilen, wie trivial eine Ausnutzung der Schwachstelle ist, oder wie zuverlässig sich damit Codeausführung erreichen lassen würde (beispielsweise durch ein Sample, dass sich gezielt gegen meine Sandbox richtet).</p>
<p class="block">Es ist aber dennoch eine subtil unangenehme Erinnerung daran, wie komplex moderne IT-Infrastruktur ist - und wie komplex wiederum die Systeme, die diese schützen sollen, ebenfalls sind. Mit allen Problemen die mit dieser Tatsache einhergehen.</p>
<p class="block"> </p>CERT.at2022-08-22T15:00:00ZLos VMware, noch einmal!CERT.at2022-08-17T14:26:05Z2022-08-16T12:00:00Z<p class="block">In den Monaten April und Mai dieses Jahres veröffentlichte VMware zwei Security Advisories (<a href="https://www.vmware.com/security/advisories/VMSA-2022-0011.html" target="_blank">VMSA-2022-0011</a> & <a href="https://www.vmware.com/security/advisories/VMSA-2022-0014.html" target="_blank">VMSA-2022-0014</a>) zu schwerwiegenden Sicherheitslücken in mehreren Produkten, zu denen teilweise bereits Patches zur Verfügung standen.</p>
<p class="block">Besagte Sicherheitsaktualisierungen wurden daraufhin von verschiedenen Bedrohungsakteuren untersucht und dienten als Basis für erste Exploits, welche wiederum bereits binnen 48 Stunden nach dem Erscheinen der Advisories genutzt wurden um großflächig Systeme zu kompromitieren</p>
<p class="block">Laut verschiedensten Berichten dauert die Ausnutzung dieser Schwachstellen auch Monate nach der Erstveröffentlichung noch weiter an - und nun konnten die Angreifer:innen ihr Arsenal um zwei weitere Sicherheitslücken erweitern.</p>
<p class="block">Konkret handelt es sich hierbei um die Schwachstellen mit den CVE-Nummern 2022-31656 und 2022-31659. Die Ausnutzung Ersterer würde Angreifer:innen die entfernte Ausführung von Code erlauben, Letztere macht eine vollständige Umgehung der Authentifizierungs- und Autorisierungsmechanismen von mehreren VMware-Produkten möglich.</p>
<p class="block">In beiden Fällen ist nichts weiter notwendig als die Möglichkeit ein verwundbares System über das Netzwerk zu erreichen. Diesmal waren für die Angreifer:innen anscheinend nicht einmal Patches zur Inspiration notwendig, laut VMWare selbst ist Code zur Ausnutzung der Schwachstelle bereits öffentlich verfügbar und wird auch eingesetzt.</p>
<p class="block">Dementsprechend sei hier mit absolutem Nachdruck empfohlen, die verfügbaren Sicherheitsaktualisierungen schnellstmöglich einzuspielen. Auch sei an dieser Stelle nochmals auf die Empfehlungen aus unserem <a href="https://cert.at/de/blog/2022/5/sicherheitslucken-in-management-interfaces" target="_blank">letzten Blogbeitrag</a> zu der Thematik hingewiesen:</p>
<ul>
<li class="block">Management-Interfaces jedweder Art sollten unter keinen Umständen ungeschützt direkt aus dem Internet erreichbar sein - oder auch nur ungehindert von jedem Endpoint innerhalb des eigenen Netzwerkes.</li>
<li class="block">Für den Fall, dass eine unbedingte betriebliche Notwendigkeit besteht, dass diese über das Internet erreichbar sind, sollte diese Notwendigkeit nochmals genauestens geprüft werden.</li>
<li class="block">Sollte danach die Notwendigkeit weiterhin bestehen sollte der Zugriff zumindest über eine gesonderte VPN-Verbindung und/oder einen besonders gesicherten Jumphost erfolgen und jegliche anderen Zugriffe auf Netzwerkebene blockiert werden - schon einfache Filterlisten sind ein erster Schritt.</li>
</ul>
<p class="block"> </p>CERT.at2022-08-16T12:00:00ZSicherheitslücken in Management InterfacesCERT.at2022-05-11T16:57:10Z2022-05-11T16:07:00Z<p class="block">Ob von <a href="https://isc.sans.edu/diary/rss/28276">HP</a>, <a href="https://www.bleepingcomputer.com/news/security/critical-sophos-firewall-vulnerability-allows-remote-code-execution/">Sophos</a>, <a href="https://security.paloaltonetworks.com/CVE-2020-2030">Palo Alto</a>, <a href="https://www.vmware.com/security/advisories/VMSA-2020-0023.html">VMware</a>, <a href="https://www.sonicwall.com/support/product-notification/security-advisory-sonicos-vulnerability-in-firewall-web-management-interface/210609115514740/">SonicWall</a> oder wie zuletzt auch <a href="https://www.heise.de/news/Jetzt-patchen-Attacken-auf-F5-BIG-IP-Systeme-koennten-bevorstehen-7079049.html">F5</a> - Sicherheitslücken in Management Interfaces sind an sich lästig genug, der Spaß (zumindest für Angreifer:innen) geht aber erst richtig los, wenn diese Management Interfaces aus dem öffentlichen Internet erreichbar sind.</p>
<p class="block">Wir alle kennen die Situation, man ist sowieso im Dauerstress, irgendetwas ist vermeintlich dringend <strong>und</strong> wichtig und plötzlich sieht die bequemere Lösung weitaus verlockender aus als die richtige und sichere (a.k.a. "Es wird schon nichts sein" oder "Unser externer Vendor muss aber auch zugreifen"). Unter Umständen hat man sich somit selbst wider besseres Wissen eine Sicherheitslücke geschaffen, die für sich genommen erstmal gar nicht so schlimm gewesen wäre. Was anfangs gerade mal für Lateral Movement getaugt hätte, ist jetzt eine ausgewachsene Unauthenticated RCE auf dem Management Interface. Sollte der schlimmste Fall tatsächlich eintreten, stellt sich alsbald die Erkenntnis (a.k.a. "Oh sh*t") ein, dass man sich damit keinen großen Gefallen getan hat.</p>
<p class="block">Positiv zu erwähnen ist, dass wir im jüngsten Fall (RCE in F5 BIG-IP Management Interface) mit Shodan keine einzige verwundbare Instanz in Österreich finden konnten - wir hoffen, dass dies ein genereller Trend im Umgang mit extern erreichbaren Management-Schnittstellen ist.</p>
<p class="block">Nochmal zur Erinnerung:</p>
<p class="block">* Management Interfaces haben im öffentlichen Internet nichts verloren. Das ist Software, Software ist voller Fehler. Nur weil man bis jetzt vielleicht keine Fehler gefunden hat, heißt das nicht, dass es keine gibt (Hint: Es gibt sie).<br />* Falls ein Zugriff von außen unbedingt erforderlich ist, sollte dieser nach Möglichkeit über ein gesondertes VPN oder einen Jumphost erfolgen.<br />* Selbst simple IP-adressbasierte Paketfilter vor dem Interface helfen bereits.</p>CERT.at2022-05-11T16:07:00ZNeuer Shadowserver-Feed: DDoS MiddleboxesCERT.at2022-04-26T14:05:08Z2022-04-26T12:38:00Z<p class="block">Wir bekommen von <a href="https://www.shadowserver.org/">Shadowserver</a> seit 2022-04-26 Daten zu Middleboxes (Firewalls, Intrusion Detection Systems, Deep Packet Inspection Gateways, etc.), die sich für DDoS Angriffe mit mitunter hohem Verstärkungsfaktor missbrauchen lassen. Der Feed ist in unseren Aussendungen als <strong>shadowserver-vulnerable-ddos-middlebox </strong>gekennzeichnet, ein entsprechender Link führt zu <a href="https://www.cert.at/de/services/daten-feeds/vulnerable/#ddos-middlebox">weiteren Informationen</a>.</p>
<p class="block">An dieser Stelle möchte ich die hervorragende Arbeit von Shadowserver hervorheben, ohne die unsere Tätigkeit bei CERT.at weitaus mühsamer wäre. Wer also noch ein paar Euros auf der hohen Kante hat und diese in etwas Sinnvolles investieren möchte, von dem die gesamte IT-Security Community profitiert, dem kann ich eine Spende an die Shadowserver Foundation ans Herz legen.</p>CERT.at2022-04-26T12:38:00ZDie Renaissance des 'Cybervigilantismus'CERT.at2022-03-11T15:24:36Z2022-03-04T09:33:00Z<p class="block">Im Rahmen unserer internationalen Partnerschaften hören wir in den letzten Tagen vermehrt von Abuse-Meldungen aus russischen Netzwerken, die sich auf vermeintliche DDoS-Angriffe aus Netzwerken europäischer Institutionen und Firmen beziehen.</p>
<p class="block"><br />Das russische nationale Koordinationszentrum für Computersicherheitsvorfälle (NCCCI) hat inzwischen auch eine Liste an IP-Adressen und Domains veröffentlicht, die angeblich an Angriffen auf russische Netzwerke beteiligt waren.</p>
<p class="block"><br />Dabei handelt es sich in den meisten Fällen allerdings nicht um schwere Angriffe mit hoher Bandbreite oder Paketanzahl, die von mit Schadsoftware infizierten "Zombies" ausgingen, sondern oftmals um viele, vergleichsweise kleine, wissentlich von einzelnen Nutzern gestartete Angriffe, die unter Ausnutzung öffentlicher Tools oder Webseiten begangen worden sind.</p>
<p class="block"><br />Der Krieg zwischen Russland und der Ukraine hat als - bis zu einem gewissen Grad überraschenden - Nebeneffekt die Renaissance von Software, die der durch Anonymous bekannt und populär gemachten, zu DDoS-Zwecken verwendeten "Low Orbit Ion Cannon" ähnelt. Dutzende solcher Programme oder auf dem selben Prinzip basierende Webseiten werden aktuell auf den sozialen Netzwerken verteilt und fast schon begeistert von vielen Menschen genutzt.</p>
<p>Das ist aus vielerlei Hinsicht problematisch:</p>
<ul>
<li>Die Programme, die in den sozialen Netzwerken zum Zweck solcher Angriffe beworben werden, sind oftmals frisch geschriebene Skripte, die in der Anleitung prominent das Deaktivieren von Sicherheitssoftware oder das Ausführen mit administrativen Berechtigungen fordern. Ganz abgesehen von der grundsätzlichen Gefahr, die von zufälligen ausführbaren Dateien im Internet ausgeht, ist es nur eine Frage der Zeit bis die ersten Programme veröffentlicht werden, die einen noch bösartigeren Zweck verfolgen, als den Angriff auf fremde Computersysteme. Trojanisierte Software lässt grüssen.</li>
<li>Infrastruktur ist nicht statisch und klar definiert. Die Pakete, die gesendet werden, verlassen nicht magisch das Endgerät und kommen am Ziel an. Dazwischen liegen dutzende, hunderte Netzwerkgeräte, Routen, Autonome Systeme, Adressbereiche und sonstige Komponenten, die das moderne Internet ausmachen. Das bedeutet, man bricht unter Umständen gleich in mehreren Jurisdiktionen Gesetze.</li>
<li>Gleichzeitig bedeutet diese technische Komplexität auch, dass möglicherweise nicht nur das eigentlich geplante Ziel getroffen wird. Kollateralschäden könnten auch Infrastruktur oder Institutionen betreffen, die der eigenen Sache (welche auch immer das sein mag) nützlich wären.</li>
<li>Dazu kommt, dass wir bereits bestätigte Berichte haben, dass Mitarbeiter:innen diese Programme nicht nur auf ihren privaten Endgeräten laufen lassen, sondern auch ihre Firmengeräte dafür nutzen, was die Sicherheitsproblematik, sowie etwaige juristische Probleme - sowohl für die Mitarbeiter:innen als auch das Unternehmen selbst - nochmals verschärft.</li>
</ul>
<p class="block">Für Sicherheitsverantwortliche gilt es hier einerseits die notwendige Awareness im Unternehmen zu schaffen und die eigenen Mitarbeiter:innen über die technischen und rechtlichen Risiken aufzuklären, die man mit der Teilnahme an solchen Angriffen eingeht und andererseits, sofern das mit vertretbarem Aufwand möglich ist, technische Massnahmen zu setzen, um solche Angriffe zu erschweren.</p>
<p class="block"><br />Beispielsweise sei hier die proxyseitige Sperre von Domains am internen Proxy genannt. So kann ich mir etwa nicht vorstellen, dass es einen relevanten Grund gibt, warum die Domain russianwarshipgofuckyourself[.]club aus dem eigenen Netz heraus erreichbar sein muss.</p>
<p class="block"><br />Auch wenn ich aus persönlicher Sicht die Frustration ob der eigenen Ohnmacht in Anbetracht der Situation in der Ukraine verstehen kann, "Cyber-Vigilantismus" ist keine Lösung. Es ist noch nicht einmal ein Lösungsansatz, sondern schafft nur noch mehr Probleme - und das nicht nur für das ursprünglich anvisierte Ziel.</p>
<p class="block"><br />Post Scriptum: Ich muss dennoch zugeben, "der Vizepremier eines europäischen Landes verkündet die Ausrufung einer sogenannten IT-Armee auf Telegram via Twitter" hatte ich definitiv nicht auf meiner Bingo-Karte für 2022.</p>
<p class="block"> </p>
<p class="block"><strong>Update, 11.03.2022:</strong> Wie befürchtet (okay: wie erwartet) wird, laut einem <a href="https://blog.talosintelligence.com/2022/03/threat-advisory-cybercriminals.html" target="_blank">Blogpost</a> von Cisco Talos, bereits Schadsoftware vertrieben, die vorgibt ein DDoS-Tool zu sein:</p>
<blockquote>Opportunistic cybercriminals are attempting to exploit Ukrainian sympathizers by offering malware purporting to be offensive cyber tools to target Russian entities. Once downloaded, these files infect unwitting users rather than delivering the tools originally advertised.</blockquote>CERT.at2022-03-04T09:33:00ZIn eigener Sache: CERT.at sucht Verstärkung (Junior IT-Security Analyst:in, IT-Security Analyst:in, Python Entwickler:in)CERT.at2022-01-28T19:17:18Z2022-01-28T19:00:00Z<p class="block">Wir suchen derzeit:</p>
<ul>
<li class="block">Berufsein- oder -umsteiger:in mit ausgeprägtem Interesse an IT-Security zur Unterstützung bei den täglich anfallenden Routineaufgaben</li>
<li class="block">IT/OT-Security Generalist:in oder Spezialist:in im Bereich Windows Security, mit Praxiserfahrung</li>
<li class="block">Python Entwickler:in zur Weiterentwicklung von bestehenden Open-Source-Projekten, insbesondere <a title="IntelMQ - Github certtools IntelMQ" href="https://github.com/certtools/intelmq/">IntelMQ</a> und <a title="Tuency - Intevation / Tuency / Tuency · GitLab" href="https://gitlab.com/intevation/tuency/tuency">Tuency</a></li>
</ul>
<p class="block">Details finden sich auf <a href="https://cert.at/de/ueber-uns/jobs/" target="_blank">unserer Jobs-Seite</a>.</p>CERT.at2022-01-28T19:00:00ZMicrosoft Patchday - jetzt neu, mit Boot-Schleife!CERT.at2022-01-12T17:15:57Z2022-01-12T16:36:00Z<p class="block">Man kann noch so viele Softwaretester beschäftigen, automatisierte Prüfungen durchführen und sonstige Sicherheitsmaßnahmen einbauen - Software beinhaltet Fehler und auch Patches, die vorherige Fehler ausbügeln sollen, sind wiederum oft selbst nicht fehlerfrei. Das ist leider eine Konstante in der IT-Welt.</p>
<p class="block">Dennoch scheint es, als hätte der Fehlerteufel bei der diesmonatigen Runde an Patches für Microsoft Windows besonders kräftig - und folgenreich - zugeschlagen. Es mehren sich im Netz Berichte über eine Vielzahl von teils gravierenden Problemen, die nach dem Einspielen der neuesten Updates auftreten. Unter anderem dürfte das Update <a href="https://support.microsoft.com/en-us/topic/january-11-2022-kb5009624-monthly-rollup-23f4910b-6bdd-475c-bb4d-c0e961aff0bc">KB5009624</a>, welches eigentlich ein Sicherheitsproblem in Bezug auf Active Directory-Attribute lösen sollte, dazu führen, dass in vielen Fällen das aktualisierte System in eine Boot-Schleife gerät. Es gibt auch <a href="https://www.borncity.com/blog/2022/01/12/windows-server-januar-2022-sicherheitsupdates-verursachen-boot-schleife/">vereinzelte Meldungen</a>, wonach das Update KB5009595 ebenfalls zu diesem Problem führen kann.</p>
<p class="block">Derer nicht genug Probleme, scheint das Update unter manchen Versionen von Windows Server auch einen automatischen Neustart zu forcieren (gerne auch regelmäßig, alle 15 Minuten, aufgrund eines abstürzenden systemrelevanten Prozesses), damit man als Administrator auch ja keinen Weg findet, das Problem vergleichsweise schmerzfrei durch Entfernen des Updates zu vermeiden. Und laut einem <a href="https://www.borncity.com/blog/2022/01/12/patchday-windows-8-1-server-2012-r2-updates-11-januar-2022-mgliche-boot-probleme/#comment-120077">Kommentar</a> unter einem Blogpost scheint das Update auch zu Problemen mit Hyper-V zu führen. Weiters gibt es (unter anderem auf <a href="https://old.reddit.com/r/Windows10/comments/s1kp76/cumulative_updates_january_11th_2022/">Reddit</a>) Berichte, dass das Update KB5009543 die Funktionalität von L2TP VPN-Verbindungen beeinträchtigt bzw. diese vollständige unbenutzbar macht.</p>
<p class="block">Es gibt viele verschiedene Wege, die eigene Infrastruktur sukzessive und vorsichtig mit Updates zu versorgen. Microsoft selbst bietet hier inzwischen teils von Haus aus Werkzeuge an (z.B. sogenannte <a href="https://docs.microsoft.com/en-us/mem/intune/protect/windows-10-update-rings">Update Rings</a>), um katastrophale Auswirkungen solcher Fehler zu vermeiden. In der Community werden auch bereits unterschiedliche <a href="https://old.reddit.com/r/sysadmin/comments/s1nybs/fsmo_domain_controller_boot_loop_from_windows/hs9kn81/">Workarounds</a> geteilt, um sich aus dieser verzwickten Lage zu befreien. Aber dennoch, auch wenn ich Verständnis dafür habe, dass in einer so komplexen Produktreihe wie Microsoft Windows Fehler unvermeidbar sind, handelt es sich hierbei doch um so schwerwiegende und anscheinend häufig auftretende Fehler, die in einem funktionierenden Q&A-Prozess, zumindest meiner unbedarften Auffassung nach, gefunden werden hätten können. Wenn nicht sogar gefunden hätten werden <strong>müssen</strong>. Ich war fast geneigt, diesen Eintrag im Einklag mit einem Kommentar auf Reddit zu betiteln:</p>
<blockquote>For fuck's sake, Microsoft</blockquote>CERT.at2022-01-12T16:36:00ZOh ... Ransomware verschlüsselt meine virtuellen Maschinen direkt im Hypervisor ... Wie jetzt?CERT.at2021-11-22T15:41:26Z2021-11-22T14:50:00Z<p class="block">Viele Ransomware- oder Ransomware-as-a-Service (RaaS)- Gruppen besitzen inzwischen die Fähigkeit, virtuelle Maschinen direkt auf Hypervisor-Ebene zu verschlüsseln. Das heisst, es sind nicht einzelne Clients, Workstations oder Server auf Windows Betriebsystem-Ebene, sondern alle Maschinen, die virtualisiert - auf zum Beispiel VMware ESXi oder Microsoft Hyper-V - laufen, gleichzeitig betroffen. Die Cybersecurityfirma Crowdstrike hat dieser Thematik zwei interessante Blog-Posts gewidmet [1][2].<br />Ein kleiner aber wichtiger Aspekt der im letzten Blog-Post beschrieben wird, ist virtuelle Maschinen (VM) bei einem Verdacht auf einen Ransomwarevorfall nicht - und ich wiederhole - NICHT zu rebooten oder herunterzufahren. Das hat folgenden Grund: Solange die VMs laufen, sind einige relevante Dateien auf der Hypervisorebene gesperrt und es kann kein externer Schreibzugriff und somit keine Verschlüsselung durch Ransomware erfolgen. Beim Herunterfahren oder auch Reboot der VMs wird diese Sperre aufgehoben und die Verschlüsselung findet umfänglich statt. Ein Problem ist, dass viele Ransomwaregruppen diesen Reboot automatisch über die Ransomware einleiten. Man sollte diesen Gruppen aber nicht proaktiv helfen, die eigene Infrastruktur zu verschlüsseln, sondern Mittel etablieren, gezielt Hypervisor-Hosts und VMs im Unternehmensnetzwerk zu isolieren.<br />Ein Grund Hypervisor-Hosts nicht durchzustarten ist, dass Ransomware meist in temporären Verzeichnissen des Hosts abgelegt wird und ein Restart diese Verzeichnisse leert und daher die Möglichkeit unterbindet die Ransomware auf potentielle Fehler der Verschlüsselung zu untersuchen. Will man hier wirklich hart eingreifen, ist die direkte Unterbrechung der Stromzufuhr durch Steckerziehen einem Herunterfahren definitiv vorzuziehen.</p>
<h2 class="block">Nun aber zu diesbezüglich etwas positiveren Themen ...</h2>
<p class="block">Da die Verschlüsselung durch Ransomware fast ausschließlich über direkt am Hypervisor-Host ausgeführte, schadhafte Software ausgeführt wird, kann man durch Unterbindung der Möglichkeit der Ausführung viel erreichen.<br />Hier kann man sich bei VMware einer Policy-Einstellung namens <em>execInstalledOnly</em> bedienen. Wird diese aktiviert, kann ausschließlich über VMware nativ installierte Software ausgeführt werden, was die Ausführung von Ransomware (Linux Binaries) auf dem Host verhindern sollte [3]. Leider hilft diese Maßnahme nicht gegen Python-basierte Ransomware Scripts (Python ist auf ESXi standarmäßig verfügbar), reduziert aber die allgemeine Angriffsfläche.<br />Bei Microsoft Hyper-V Servern sollte eine rigide Application Allowlist (früher Whitelist) etabliert werden, was auf Grund von einer recht überschaubaren Menge an Standardsoftware auf diesen Systemen ein geringer Aufwand sein sollte. Die Einstellungen diesbezüglich benötigen keine Zusatzsoftware [4].</p>
<p class="block"> <strong>Die hier beschrieben Maßnahmen sind in keinster Weise als umfassender Schutz vor Ransomware auf Hypervisoren zu verstehen, sondern stellen ausschließlich exemplarisch Möglichkeiten dar.</strong></p>
<p class="block"> </p>
<p class="block">[1] <a href="https://www.crowdstrike.com/blog/carbon-spider-sprite-spider-target-esxi-servers-with-ransomware/">https://www.crowdstrike.com/blog/carbon-spider-sprite-spider-target-esxi-servers-with-ransomware/</a><br />[2] <a href="https://www.crowdstrike.com/blog/hypervisor-jackpotting-ecrime-actors-increase-targeting-of-esxi-servers/">https://www.crowdstrike.com/blog/hypervisor-jackpotting-ecrime-actors-increase-targeting-of-esxi-servers/</a><br />[3] <a href="https://www.truesec.com/hub/blog/secure-your-vmware-esxi-hosts-against-ransomware">https://www.truesec.com/hub/blog/secure-your-vmware-esxi-hosts-against-ransomware</a><br />[4] <a href="https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control">https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control</a></p>CERT.at2021-11-22T14:50:00ZEin paar Bemerkungen zum Stand der NIS2 DiskussionenCERT.at2021-11-16T12:14:29Z2021-11-16T10:09:00Z<p class="block">Da dieser Text für Leser in der ganzen EU relevant sein könnte, hab ich ihn auf Englisch geschrieben und er ist daher im<a href="https://cert.at/en/blog/2021/11/an-update-on-the-state-of-the-nis2-draft"> englischen Teil unserer Webseite</a>.</p>CERT.at2021-11-16T10:09:00ZEU Digital Green Certificate: Was gilt eigentlich bei uns?CERT.at2021-10-29T18:00:44Z2021-10-29T16:48:00Z<p class="block">Nachdem der digitale grüne Pass gerade in den Medien ist, und ich für den<a href="https://www.derstandard.at/story/2000130748869/datenleck-gruene-paesse-muessen-moeglicherweise-neu-ausgestellt-werden"> Standard den Erklärbären</a> mache, will ich hier ein paar technische Informationen dokumentieren, die für einen Zeitungsartikel dann doch zu technisch sind.</p>
<p class="block">Erstmal: die Technik hinter dem Grünen Pass ist keine Hexerei. Da sind keine magischen oder geheimen Zutaten dabei. Das ganze Projekt wurde extrem offen entwickelt und <a href="https://github.com/ehn-dcc-development">dokumentiert</a> und baut auf einer Reihe von offenen Standards auf. Auch wurde ganz viel der <a href="https://github.com/eu-digital-green-certificates">Software</a>, die in diesem Kontext geschrieben wurde, als Open Source auf github veröffentlicht.</p>
<p class="block">Ich hab mir im Sommer schon mal <a href="https://lendl.priv.at/blog/2021/07/11/parsing-the-eu-digital-covid-certificate/">privat angeschaut</a>, wie so ein QR code aufgebaut ist. Kurz zusammengefasst geht das so:</p>
<ul>
<li class="block">Scannt man den QR-Code, bekommt man einen ASCII String</li>
<li class="block">Der wird per <a href="https://datatracker.ietf.org/doc/draft-faltstrom-base45/">base45</a> in eine Folge von Bytes konvertiert</li>
<li class="block">Das wird per <a href="https://datatracker.ietf.org/doc/html/rfc1950">zlib</a> entpackt</li>
<li class="block">Jetzt haben wir eine <a href="https://datatracker.ietf.org/doc/html/rfc8949">CBOR</a>-Struktur (quasi JSON, aber binär kodiert)</li>
<li class="block">Diese ist per <a href="https://datatracker.ietf.org/doc/html/rfc8152">COSE Standard</a> signiert</li>
<li class="block">Und im signierten Teil sind dann die eigentlichen Datenfelder, die die Impfung beschreiben</li>
</ul>
<p class="block">Nachdem jetzt <a href="https://threatpost.com/eus-green-pass-vaccination-id-private-key-leaked/175857/">berichtet wurde</a>, dass mit dem Schlüssel von Nord-Mazedonien sinnlose Grüne Pässe signiert wurde, wollte ich nachschauen, wie Österreich reagiert hat.</p>
<p class="block">Auch die Implementation Österreichs ist ausgiebig auf <a href="https://github.com/Federal-Ministry-of-Health-AT/green-pass-overview#readme">Github dokumentiert</a>. Man findet sehr schnell, dass die Liste der Digitalen Schlüssel, deren Unterschrift von unserer "Green Check" App anerkannt wird, per <a href="https://dgc-trust.qr.gv.at/trustlist">https://dgc-trust.qr.gv.at/trustlist</a> verteilt wird.</p>
<p class="block"><strong>Wie kann man sich das File mit Linux Bordmitteln anschauen?</strong></p>
<p class="block"><code>$ wget <a href="https://dgc-trust.qr.gv.at/trustlist">https://dgc-trust.qr.gv.at/trustlist</a></code></p>
<p class="block">Da meine toolchain für cbor ziemlich leer ist, hab ich <a href="https://github.com/dflemstr/rq">rq installiert</a>, damit kann ich dann per</p>
<p class="block"><code>$ cat trustlist | rq -c -J | jq .c > trustlist.json</code></p>
<p class="block">in die JSON-Welt wechseln. Das ergibt einen JSON Array von Hashes, wobei "c" das Zertifikat im DER Format und "i" die Keyid ist. Da JSON keine binären Daten enthalten kann, hat rq das jeweils als Array von Bytes kodiert. Mit einem kleinen Perl-Script lassen sich die DER Files extrahieren:</p>
<pre class="block">#!/usr/bin/perl -w
use strict;
use JSON;
my $json = JSON->new->allow_nonref;
my $text = "";
while (<>) { $text .= $_ };
my $certs = $json->decode( $text );
my ($c, $i, $cstr, $istr);
foreach my $cert (@$certs) {
$i = $cert->{i};
$c = $cert->{c};
$istr = join("", map { sprintf("%02x",$_) } @$i);
$cstr = pack("C*", @$c);
open(F, ">$istr.der"); print F $cstr; close(F);
}</pre>
<p class="block"> Dank openssl kann man die DER Files lesbar machen:<br /><code>for f in *der ; do openssl x509 -in $f -inform DER -noout -text > $f.text; done</code></p>
<p class="block">Der Public Key, mit dem Österreich die hiesigen Grünen Pässe signiert, ist dieser:</p>
<pre class="block">Certificate:
Data:
Version: 3 (0x2)
Serial Number:
01:79:cc:f8:be:3b:7e:60:5c:7b
Signature Algorithm: ecdsa-with-SHA256
Issuer: C = AT, O = BMSGPK, serialNumber = 001, CN = AT DGC CSCA 1
Validity
Not Before: Jun 2 13:45:24 2021 GMT
Not After : Jun 2 13:45:24 2023 GMT
Subject: C = AT, O = BMSGPK, serialNumber = 001001, CN = AT DGC DSC 1
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:60:4d:b8:a8:82:a6:75:c7:d1:59:48:76:4e:a9:
25:91:f6:7a:9f:23:41:a5:7e:15:1d:e2:cc:c5:f1:
65:f2:b9:10:f1:99:2e:d1:b7:27:1f:93:99:5d:c9:
24:4a:df:ad:2a:cf:85:19:9f:6d:28:9d:55:b4:d0:
e6:79:d9:4b:eb
ASN1 OID: prime256v1
NIST CURVE: P-256
</pre>
<p class="block"> Ein "<code>fgrep -h Subject: *text</code>" zeigt alle 203 Schüssel, denen Österreich aktuell vertraut. Aus welchen Ländern kommen diese?</p>
<pre class="block">$ fgrep -h Subject: *text | perl -p -e 's/.* C = (\w+).*/$1/' | sort -u | xargs echo <br />AD AL AM AT BE BG CH CY CZ DE DK EE ES FI FO FR GB GR HR HU IE IL IS IT LI LT LU LV <br />MA MC MK MT NL NO PA PL PT RO SE SI SK SM TR UA VA</pre>
<p class="block"> Viele Staaten verwenden nur einen Schlüssel, manche aber auch mehrere:</p>
<pre class="block">$ fgrep -h Subject: *text | perl -p -e 's/.* C = (\w+).*/$1/' | sort | uniq -c| sort -rn
57 DE
32 FR
21 ES
12 NL
12 CH
7 GB
6 MT
6 LU
</pre>
<p class="block"><strong>Und was ist mit Mazedonien? </strong>Der Schlüssel mit CC = MK wurde erst gestern erzeugt. Man hat also reagiert, und den alten Schlüssel widerrufen (und damit alle von ihm signierten Grünen Pässe ungültig gemacht) und durch einen neuen ersetzt.</p>
<p class="block"><strong>Zusammenfassung</strong>: Das System ist ausgesprochen transparent. Ich habe für diese Analyse kein Insiderwissen gebraucht.</p>CERT.at2021-10-29T16:48:00ZRückblick auf das zweite Drittel 2021CERT.at2021-09-23T08:11:47Z2021-09-23T05:28:00Z<p class="block">Dieser Bericht ist auch als PDF verfügbar: <a class="pdf" title="https://cert.at/media/files/news/blog/20210922/2021-09-jahresdrittel02.pdf" href="https://cert.at/media/files/news/blog/20210922/2021-09-jahresdrittel02.pdf">Download</a></p>
<h3 id="inhalt">Inhalt</h3>
<ul>
<li><a href="#vorfaelle-aussendungen">Vorfälle und Aussendungen</a></li>
<ul>
<li><a href="#proxylogon">ProxyLogon</a></li>
<li><a href="#21nails">21 Nägel für <code>exim</code></a></li>
<li><a href="#vmware-vcenter">VMware vCenter</a></li>
<li><a href="#ddos-erpressungen">DDoS Erpressungen</a></li>
<li><a href="#printnightmare">PrintNightmare</a></li>
<li><a href="#proxyshell">ProxyShell</a></li>
<li><a href="#proxytoken">ProxyToken</a></li>
</ul>
<li><a href="#projekte-vortraege">Projekte und Vorträge</a></li>
<ul>
<li><a href="#melicertes2">MeliCERTes 2 (SMART-2018-2014)</a></li>
<li><a href="#cef-2018">“Enhancing Cybersecurity in Austria" (2018-AT-IA-0111)</a></li>
<ul>
<li><a href="#trainings-und-konferenzen">Trainings und Konferenzen</a></li>
<li><a href="#tooling">Tooling</a></li>
</ul>
<li><a href="#vortraege">Vorträge</a></li>
</ul>
</ul>
<h2 id="vorfaelle-aussendungen">Vorfälle und Aussendungen</h2>
<p>Insgesamt verlief das zweite Jahresdrittel 2021 sehr Microsoft-lastig: Neben den Nachwehen von <a href="https://proxylogon.com/">ProxyLogon</a>, wurde mit <a href="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell">ProxyShell</a> eine weitere Exploit-Chain für Microsoft Exchange Server bekannt, und <a href="https://us-cert.cisa.gov/ncas/current-activity/2021/06/30/printnightmare-critical-windows-print-spooler-vulnerability">PrintNightmare</a>, eine Schwachstelle im Windows Printer Spooler entwickelte sich zu einer Fortsetzungsgeschichte, in der Patch um Patch das Problem nur unzureichend beheben konnte.</p>
<p>Außerdem wurden teilweise uralte, schwerwiegende Lücken in der Mailserversoftware <code>exim</code> entdeckt, eine RCE in VMware vCenter gefunden und Erpressungen via DDoS versucht.</p>
<h3 id="proxylogon">ProxyLogon</h3>
<p>Die im März mit einem Notfallpatch behobene Exploit-Chain für Microsoft Exchange Server, konnte auch im zweiten Jahresdrittel nicht vollständig ad-acta gelegt werden: Die initiale Patch-Disziplin war in diesem Fall extrem hoch, wie wir z.B. <a href="https://cert.at/de/aktuelles/2021/3/aktuelle-zahlen-zu-den-proxylogon-exchange-schwachstellen-in-osterreich">in diesem Post</a> dargelegt haben, und Ende August 2021 waren laut unseren Informationen nur noch etwa 60 von rund 2500 uns bekannten Exchange Installationen anfällig für diese Schwachstellen. Das ist insgesamt sehr erfreulich, zumal davon ausgegangen werden kann, dass einige dieser Instanzen HoneyPots sind.</p>
<p>Der Verlauf der verwundbaren Installationen über das zweite Jahresdrittel in Österreich wird in der folgenden Abbildung dargestellt.</p>
<p><img src="https://cert.at/media/files/news/blog/20210922/proxylogon.svg" alt="ProxyLogon in Österreich" width="100%" /></p>
<h3 id="21nails">21 Nägel für <code>exim</code></h3>
<p>Nicht nur Microsofts E-Mail-Server wurde 2021 von IT-Security ResearcherInnen ein schlechtes Zeugnis ausgestellt: Die Firma Qualys warf einen genaueren Blick auf <a href="https://www.exim.org/"><code>exim</code></a> und fand dabei 21 Sicherheitslücken, von denen einige nicht nur potentiell die Übernahme des Servers ermöglichten, sondern bereits seit dem Beginn von <code>exim</code>s Git-History im Jahr 2004 ausnutzbar waren. Details dazu finden Sie <a href="https://www.qualys.com/2021/05/04/21nails/21nails.txt">im Advisory von Qualys</a>.</p>
<p>Wir veröffentlichten <a href="https://cert.at/de/warnungen/2021/5/kritische-sicherheitslucken-im-exim-e-mail-server-patches-verfugbar">eine Warnung zu den Schwachstellen</a>, führten allerdings in diesem Fall keine Scans nach potentiell Betroffenen durch, um diese direkt zu informieren. Dafür gab es zwei Gründe:</p>
<ul>
<li>
<p>Viele Linux-Distributionen passen den Versions-String von <code>exim</code> (und anderer Software) entsprechend ihrer eigenen Release-Zyklen an und verwenden nicht jenen von <code>exim</code> selbst. Entsprechend hätte ein einfacher Vergleich zwischen den zurückgelieferten Versions-Strings mit jenem, den <code>exim</code> für die gepatchte Version angab, zu zahlreichen False Positives geführt.</p>
</li>
<li>
<p>Eine direkte Überprüfung der Lücken war aus unsere Sicht zu riskant, da hier Zugriff auf potentiell sensible Daten oder ein Systemabsturz die Folge hätten sein können.</p>
</li>
</ul>
<h3 id="vmware-vcenter">VMware vCenter</h3>
<p>Im Mai veröffentlichte VMware in <a href="https://www.vmware.com/security/advisories/VMSA-2021-0010.html">VMSA-2021-0010</a> Workarounds und Updates zu <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-21985">CVE-2021-21985</a>, einer Remote Code Execution Schwachstelle in VMware vCenter, die es AngreiferInnen ermöglichte, beliebige Befehle mit <code>root</code>-Rechten auf dem Server auszuführen. Die einzige Voraussetzung war Zugriff auf Port 443/TCP.</p>
<p>Wir haben daraufhin via <a href="https://www.shodan.io/">Shodan</a> nach allen potentiell verwundbaren Installationen in Österreich gesucht und die Betroffenen informiert.</p>
<h3 id="ddos-erpressungen">DDoS Erpressungen</h3>
<p>Im Mai und Juni gingen bei uns zahlreiche Meldungen von Unternehmen ein, dass eine Gruppe Krimineller, die sich “Fancy Lazarus" nannte, DDoS-Angriffe gegen sie durchgefüht hatte und drohte, dass wesentlich stärkere Angriffe folgen würden, wenn die Unternehmen nicht eine Lösegeldforderung von einigen BitCoins zahlen würden.<a id="fnref1" class="footnote-ref" href="#fn1"><sup>1</sup></a></p>
<p>Da diese Gruppe nicht nur in Österreich aktiv war, tauschten wir uns mit einigen anderen CERTs/CSIRTs im europäischen Umfeld aus und hatten entsprechend einen guten Überblick zur Vorgehensweise von “Fancy Lazarus": Während die Initialangriffe oft gegen die authoritativen Nameserver geführt wurden und die Services betroffener Firmen dadurch von außen unerreichbar schienen, waren die angedrohten Folgeangriffe auch nach Ablauf der Zahlungsfrist nirgends durchgeführt worden. Diese Erkenntnisse sowie Tipps, wie sich Unternehmen generell auf DDoS-Angriffe vorbereiten können, veröffentlichten wir <a href="https://cert.at/de/warnungen/2021/6/ddos-angriffe-gegen-unternehmen-in-osterreich">in einer Warnung</a>.</p>
<p>Uns ist nach wie vor kein Fall bekannt, in dem die Gruppe ihre Drohung wahr machte und tatsächlich stärkere Folgeangriffe durchführte.</p>
<h3 id="printnightmare">PrintNightmare</h3>
<p>Am 8. Juni veröffentlichte CERT/CC eine <a href="https://www.kb.cert.org/vuls/id/383432">technisch detaillierte Beschreibung</a> von <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-1675">CVE-2021-1675</a>, einer Remote Code Execution Schwachstelle im Windows Print Spooler die im Zuge des Juni-Updates für Microsoft Windows behoben worden war.</p>
<p>Allerdings stellte sich schnell heraus, dass der Patch nicht ausreichend war und innerhalb kurzer Zeit tauchte Exploit-Code auf. Microsoft erklärte daraufhin, dass der Patch sehr wohl wirksam sei und es sich um eine neue, lediglich ähnliche Lücke handle, für die auch eine neue CVE (<a href="https://nvd.nist.gov/vuln/detail/CVE-2021-34527">CVE-2021-34527</a>) vergeben wurde. Diese erhielt dann auch explizit den Namen “PrintNightmare" und wurde offiziell in den Juli-Updates von Microsoft behoben, aber wiederum konnten Security-ResearcherInnen innerhalb kurzer Zeit zeigen, dass die Probleme nicht vollständig behoben waren.</p>
<p>Microsoft vergab wiederum neue CVE-Nummern für diese Lücken (<a href="https://nvd.nist.gov/vuln/detail/CVE-2021-34481">CVE-2021-34481</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-36936">CVE-2021-36936</a>, und <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-36947">CVE-2021-36947</a>), die am Microsoft Patchday im August behoben werden sollten. Security Researcher und Entwickler von <a href="https://github.com/gentilkiwi/mimikatz"><code>mimikatz</code></a>, Benjamin Delpy, zweifelte deren Wirksamkeit jedoch noch am Tag des Erscheinens der Patches an, da <code>mimikatz</code>’s Exploit nach wie vor funktionierte.</p>
<p>Als Reaktion veröffentlichte Microsoft einen Tag nach dem August Patchday mit <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-36958">CVE-2021-36958</a> eine weitere CVE-Nummer, für die lediglich ein Workaround zur Verfügung gestellt wurde, der schlicht darin besteht, den Print Spooler Service zu deaktivieren, was in vielen Unternehmen nicht möglich ist.</p>
<p>Wir verfassten dazu <a href="https://cert.at/de/warnungen/2021/7/printnightmare-kritische-sicherheitslucke-in-microsoft-windows-print-spooler-service-workarounds-verfugbar">eine mehrmals aktualisierte Warnung</a> und hoffen, dass wir uns von diesen Schwachstellen im September endgültig verabschieden dürfen.</p>
<h3 id="proxyshell">ProxyShell</h3>
<p>Im Zuge der Blackhat 2021 USA hielt der Security-Researcher Orange Tsai einen Vortrag mit dem Titel “ProxyLogon is Just the Tip of the Iceberg" (die Folien dazu finden Sie <a href="https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ProxyLogon-Is-Just-The-Tip-Of-The-Iceberg-A-New-Attack-Surface-On-Microsoft-Exchange-Server.pdf">auf der Webseite der Blackhat</a>; ein Blogpost von Orange Tsai mit technischen Details erschien kurz darauf bei der <a href="https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell">Zero Day Initiative</a>) in dem er generell die Angriffsmöglichkeiten auf Microsoft Exchange Server vorstellte und spezifisch eine neue Exploit-Chain präsentierte, über die AngreiferInnen über das Netzwerk beliebige Befehle als <code>NT Authority\SYSTEM</code> ausführen konnten, ohne über gültige Zugangsdaten zu verfügen. Diese “ProxyShell" genannte Kombination von Schwachstellen ist damit ebenso katastrophal wie ProxyLogon vom März 2021. Der einzige Unterschied bestand darin, dass ProxyShell zum Veröffentlichungszeitpunkt noch nicht aktiv ausgenutzt und die dazugehörigen Lücken bereits in den Exchange-Updates von April bzw. Mai 2021 behoben worden waren.</p>
<p>Kurz danach veröffentlichte der <a href="https://twitter.com/GossiTheDog">Sicherheitsforscher Kevin Beaumont</a> ein <a href="https://github.com/GossiTheDog/scanning/blob/main/http-vuln-exchange-proxyshell.nse"><code>nmap</code> Script</a>, mit dessen Hilfe verwundbare Server identifiziert werden konnten, es <a href="https://heise.de/-6158946">wurde aktiv nach verwundbaren Servern gescannt</a> und bald darauf <a href="https://heise.de/-6164957">wurden auch erste Angriffe bekannt</a>.</p>
<p>Wir haben daraufhin die Logik von Kevin Beaumonts <code>nmap</code> Script in Python implementiert und einen zusätzlichen Test über die Versionsnummer eingebaut, anschließend alle uns bekannten Exchange Server in Österreich überprüft und die Abuse-Kontakte aller potentiell verwundbaren Installation kontaktiert. Die ersten Ergebnisse haben wir <a href="https://cert.at/de/aktuelles/2021/8/proxyshell-in-osterreich">auf unserer Webseite</a> beschrieben. Im Laufe des Augusts haben wir einige weitere Scans und Aussendungen durchgeführt. Die Entwicklung der verwundbaren Server in Österreich, sieht dabei wie folgt aus:</p>
<p><img src="https://cert.at/media/files/news/blog/20210922/proxyshell.svg" alt="ProxyShell in Österreich" width="100%" /></p>
<h3 id="proxytoken">ProxyToken</h3>
<p>Kurz vor Ende des zweiten Jahresdrittels wurde mit <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-33766">CVE-2021-33766</a> eine weitere schwere Schwachstelle in Microsoft Exchange Servern gefunden, die, der aktuellen Namenskonvention folgend, “ProxyToken" genannt wurde und <a href="https://www.zerodayinitiative.com/blog/2021/8/30/proxytoken-an-authentication-bypass-in-microsoft-exchange-server">in einer Veröffentlichung der Zero Day Initiative</a> näher beschrieben wird. Es ist allerdings festzuhalten, dass es sich hierbei um eine einzelne Lücke handelt, nicht um eine ganze Exploit-Chain wie bei ProxyLogon und ProxyShell.</p>
<p>Obwohl ProxyToken zwar nicht zu einer Remote Code Execution als <code>NT Authority\SYSTEM</code> führt, sondern AngreiferInnen “nur" die Re-Konfiguration beliebiger Postfächern ohne Authentifizierung erlaubt, ist sie dennoch extrem gefährlich: Sie müssen lediglich wissen, dass ein Postfach existiert, um z.B. eine Weiterleitung zu einer E-Mail-Adresse unter ihrer Kontrolle einzurichten.</p>
<p>ProxyToken wurde im Zuge von Microsofts Patchday im Juli 2021 behoben,<a id="fnref2" class="footnote-ref" href="#fn2"><sup>2</sup></a> öffentliche Exploits waren aber bald nach Erscheinen des oben erwähnten Posts von ZDI verfügbar.</p>
<h2 id="projekte-vortraege">Projekte und Vorträge</h2>
<h3 id="melicertes2">MeliCERTes 2 (SMART-2018-2014)</h3>
<p>Nachdem die Anforderungen an die Single-Sign-On Lösung für das <a href="https://csirtsnetwork.eu/">CSIRTs Network</a> (CNW) fertig ausdefiniert waren, wurde eine Studie erstellt, wie gut diverse Open Source Lösungen diese erfüllen können. Dabei wurden die Dokumentationen, der Status (Projektaktivität, Verfügbarkeit von kommerziellem Support, etc.) sowie der Security Track Record miteinbezogen.</p>
<p>Von den Top Drei (<a href="https://wso2.com/">WSO2</a>, <a href="https://www.keycloak.org/">Keycloak</a>, <a href="https://gluu.org/">Gluu</a>) wurden anschließend Testinstallationen durchgeführt, um die Anbindung der relevanten Applikationen zu testen. Dabei hat sich herausgestellt, dass die Integration von SharePoint am problematischsten ist: Die On-Premise Version unterstützt nur WS-Fed (<a href="https://en.wikipedia.org/wiki/WS-Federation">Web Services Federation</a>), und wird ADFS (<a href="https://docs.microsoft.com/en-us/windows-server/identity/active-directory-federation-services">Active Directory Federation Services</a>) als Integrationslayer eingesetzt, zeigt sich, dass auch dort die Unterstützung für SAML (<a href="https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language">Security Assertion Markup Language</a>) und OIDC (<a href="https://en.wikipedia.org/wiki/OpenID#OpenID_Connect_(OIDC)">OpenID Connect</a>), zwei weit verbreiteten Standards auf diesem Gebiet, mangelhaft und veraltet ist. Dieser Umstand spiegelt deutlich Microsofts Strategie wider, KundInnen zur Nutzung der Cloud-Services zu drängen, während die Unterstützung aktueller, offener Standards in den On-Premise Varianten keine Priorität hat. Das CSIRTs Network kann sich diesen Vendor Lock-in auf Dauer nicht leisten.</p>
<p>Im Sommer wurde dann ausgiebig an den Verfügbarkeitserwartungen des CSIRTs Network bzgl. der von der ENISA betriebenen Systemen gearbeitet. Dazu gab es eine Umfrage im CNW, welche Ausfallszeiten für welche Services akzeptabel sind. Eingeteilt in Bürozeiten/außerhalb, Kern- und Zusatzservices und Normalbetrieb versus Krisenmodus des CNW ergab das in Summe acht Werte für die angestrebten Wiederanlaufzeiten. Während die CSIRTs solche Verfügbarkeitsanforderungen gewohnt sind (die auch von der NIS Direktive abgeleitet werden), hatte die ENISA bis zum <a href="https://digital-strategy.ec.europa.eu/en/policies/cybersecurity-act">EU Cyber Security Act</a> von 2019 keine operativen Aufgaben und daher auch keinen Bedarf für einen hochverfügbaren IT Betrieb. Inzwischen kamen mit dem neuen Mandat operative Aufgaben dazu und es wurde klar, dass die Rolle des Sekretariats für das CSIRTs Network und das Cyber Crisis Liaison Organisation Network (CyCLONe) sich nicht nur auf die Organisation von Meetings beschränkt, sondern auch den Betrieb von IT Infrastruktur erfordert. Das MeliCERTes 2 Konsortium hilft der ENISA bei der Umstellung auf diese neuen Anforderungen.</p>
<p>Davon unabhängig wurden auch wieder Workshops und Trainings zu IntelMQ für die Mitglieder des CNW abgehalten.</p>
<h3 id="cef-2018">“Enhancing Cybersecurity in Austria" (2018-AT-IA-0111)</h3>
<p>Da dieses Projekt mit Ende August 2021 auslief, war die Arbeit im zweiten Jahresdrittel auf den Projektabschluss und die dabei abzugebenden Berichte fokussiert.</p>
<h4 id="trainings-und-konferenzen">Trainings und Konferenzen</h4>
<p>Wie auch im Vorjahr wurden die FIRST Conference und das dazugehörige Capture The Flag (CTF) Event 2021 online abgehalten. Thomas Pribitzer, Dimitri Robl und Sebastian Waldbauer von CERT.at nahmen als Team am CTF teil und belegten am Ende den 9. Platz von 42. Teams. Dazu gibt es auch ein längeres <a href="https://cert.at/en/blog/2021/6/first-challenge-2021-writeup">Writeup auf Englisch</a>.</p>
<p>Im Juli besuchte Thomas Pribitzer <a href="https://www.sans.org/cyber-security-courses/cyber-security-writing-hack-the-reader/">SANS SEC402: Cybersecurity Writing: Hack the Reader</a> als on-demand online Kurs. Im August absolvierte Dimitri Robl das <a href="https://www.infosecinstitute.com/skills/learning-paths/windows-10-host-security/">Windows Host Security Training des InfoSec Institutes</a> und Thomas Pribitzer schloss <a href="https://www.infosecinstitute.com/skills/learning-paths/comptia-network/">deren CompTIA Network+ Learning Path</a> ab.</p>
<p>Auch wenn es weiterhin COVID-19-bedingt kaum möglich war, physische Konferenzen zu besuchen, so konnten wir im Rahmen dieses CEF-Projekts am 63. TF-CSIRT Meeting im Mai und am 14. CSIRTs Network Meeting im Juni jeweils virtuell teilnehmen.</p>
<p>Außerdem organisierte und leitete Otmar Lendl im Juni einen Hackaton zum Thema RTIR-Statistiken für die Mitglieder des CSIRTs Network.</p>
<h4 id="tooling">Tooling</h4>
<p>Am 2. Juli wurde mit IntelMQ 3.0.0 eine rundum überarbeitete Version von <a href="https://github.com/certtools/intelmq">IntelMQ</a> veröffentlicht und damit auch ein wesentlicher Milestone für das Projekt erreicht. Einen Überblick zu den Änderungen und Umbauten finden Sie <a href="https://cert.at/en/blog/2021/8/intelmq-30-domain-based-workflow-ieps">auf unserem Blog</a>.</p>
<p>Neben IntelMQ 3.0 wurde zeitgleich die erste stabile Version von "Tuency", unserem neuen “Constituency-Portal", veröffentlicht. Das Portal ist ein Kontaktmanagementtool mit Self-Service Funktionen und verwendet als Authentifizerungslösung <a href="https://www.keycloak.org/">Keycloak</a>. Dadurch können die dort hinterlegten Zugangsdaten auch bei anderen, zukünftigen Diensten verwendet werden. Das Portal verbessert und erweitert außerdem die Adressierung unserer täglichen E-Mailbenachrichtigungen an NetzbetreiberInnen über Probleme in deren Netzen, die wir via IntelMQ ausschicken. Eine genauere Beschreibung der Funktionen finden Sie <a href="https://cert.at/en/blog/2021/9/tuency-constituency-portal-for-iocs-and-certs">in unserem Blogpost dazu</a>. Der Source-Code von Tuency ist <a href="https://gitlab.com/intevation/tuency/tuency">öffentlich auf GitLab einsehbar</a>. Vor der Veröffentlichung wurde ein Pentest durch Externe durchgeführt, der kleine Verbesserungsmöglichkeiten fand, insgesamt aber das sichere Design und die robuste Ausführung des Projekts bestätigte.</p>
<p>Außerdem haben wir im zweiten Jahresdrittel umgesetzt, dass unsere öffentlichen Datenfeeds via IntelMQ in unser SIEM eingespeist werden. Entsprechend ist es jetzt möglich, dessen Logs mit den Feeds zu korrelieren und effizienter auf Probleme zu reagieren.</p>
<p>Ebenfalls abschließen konnten wir die Integration der MeliCERTes Plattform, unter anderem durch die Installation von <a href="https://github.com/cerebrate-project/cerebrate/">Cerebrate</a>. Diese Software ermöglicht allen Mitgliedern des CSIRTs Network, eine gemeinsame Authentifizierungslösung zu betreiben. Für die erfolgreiche Umsetzung war es notwendig, im IT Betrieb technische Grundlagen und Kompetenzen zu schaffen und auszubauen.</p>
<p>Als finalen “Test" für die Integration von MeliCERTes führten wir gemeinsam mit <a href="https://www.ria.ee/en/cyber-security/cert-ee.html">CERT.ee</a> den ersten erfolgreichen Inter-Operability Test zwischen zwei MeliCERTes Installationen durch.</p>
<h3 id="vortraege">Vorträge</h3>
<ul>
<li>
<p>Im April moderierte Wolfgang Rosenkranz die Vorstellung der Ergebnisse der letzten Cyber Security Studie des <a href="https://kuratorium-sicheres-oesterreich.at/">Kuratorium Sicheres Österreich (KSÖ)</a>.</p>
</li>
<li>
<p>Im Mai präsentierte Sebastian Wagner IntelMQ 3.0 und die damit einhergehenden Veränderungen am 63. TF-CSIRT Meeting.</p>
</li>
<li>
<p>Im gleichen Monat hielt Birger Schacht einen interaktiven Workshop zu IntelMQ im Rahmen des MeliCERTes 2 Projekts.</p>
</li>
<li>
<p>Im Juni hielt Dimitri Robl an der Universität Wien einen Gastvortrag im Zuge der <a href="https://ufind.univie.ac.at/de/course.html?lv=052712&semester=2021S">Lehrveranstaltung “Network Security"</a>.</p>
</li>
<li>
<p>Im August sprach Dimitri Robl vor dem <a href="https://www.staedtebund.gv.at/ausschuesse/informationstechnologie-und-digitalisierung/organisation/">Fachausschuss für Informationstechnologie des Städtebunds</a> über die aktuelle Lage in der IT-Sicherheit, welche Bedrohungen 2021 besonders wichtig waren und welche wohl oder übel noch länger relevant bleiben werden. Außerdem wurde besprochen, wie die Zusammenarbeit zwischen GovCERT Austria und dem Städtebund intensiviert werdenn könnte.</p>
</li>
</ul>
<section class="footnotes"><hr />
<ol>
<li id="fn1">
<p>Der Name der Gruppe dürfte ein Versuch sein, die Opfer einzuschüchtern, da er sich aus Teilen von “Fancy Bear" und “Lazarus" zusammensetzt, zwei APTs (Advanced Persistent Threats) von denen angenommen wird, dass sie staatlich finanziert sind; siehe <a href="https://attack.mitre.org/groups/G0032/">https://attack.mitre.org/groups/G0032/</a> und <a href="https://attack.mitre.org/groups/G0007/">https://attack.mitre.org/groups/G0007/</a>. Eine tatsächliche Verbindung zu diesen Gruppen ist äußerst unwahrscheinlich.<a class="footnote-back" href="#fnref1">↩︎</a></p>
</li>
<li id="fn2">
<p>Um diesen Umstand gibt es etwas Verwirrung, denn <a href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-33766">Microsofts Advisory zu CVE-2021-33766</a> schreibt, dass bereits die Updates im April das Problem behoben hatten, allerdings darauf vergessen wurde, die CVE-Nummer dort anzuführen. Entsprechend dürften auch Exchange Server mit Patchstand April 2021 gegen die Lücke abgesichert sein, wir konnten dies aber nicht testen.<a class="footnote-back" href="#fnref2">↩︎</a></p>
</li>
</ol>
</section>CERT.at2021-09-23T05:28:00ZRückblick auf das erste Drittel 2021CERT.at2021-05-27T08:52:00Z2021-05-27T08:00:00Z<h1 id="das-erste-jahresdrittel-2021">Das erste Jahresdrittel 2021</h1>
<p class="block">Dieser Bericht ist auch als PDF erhältlich: <a class="pdf" title="https://cert.at/media/files/news/blog/20210527/2021-05-jahresdrittel01.pdf" href="https://cert.at/media/files/news/blog/20210527/2021-05-jahresdrittel01.pdf">Download</a></p>
<ul>
<li class="block"><a href="#vorfaelle-aussendungen">Vorfälle und Aussendungen</a><br />
<ul>
<li class="block"><a href="#dnspooq">DnSpooq</a></li>
<li class="block"><a href="#emotet">Emotet Takedown und die Folgen</a></li>
<li class="block"><a href="#ms-exchange">Microsoft Exchange Notfallpatches</a></li>
<li class="block"><a href="#silverfish">SilverFish APT</a></li>
<li class="block"><a href="#pulse-connect-secure">Pulse Connect Secure</a></li>
<li class="block"><a href="#sonicwall-email-security">SonicWall Email Security</a></li>
</ul>
</li>
<li class="block"><a href="#projekte-konferenzen">Projekte und Konferenzen</a><br />
<ul>
<li class="block"><a href="#melicertes">MeliCERTes 2 (SMART-2018-2014)</a></li>
<li class="block"><a href="#cef-2018">“Enhancing Cybersecurity in Austria” (2018-AT-IA-0111)</a></li>
<li class="block"><a href="#vortraege">Vorträge</a></li>
</ul>
</li>
</ul>
<h2 id="vorfaelle-aussendungen">Vorfälle und Aussendungen</h2>
<h3 id="dnspooq">DnSpooq</h3>
<p>Am 2021-01-19 veröffentlichte JSOF eine Reihe von Schwachstellen in <code>dnsmasq</code>, einer populären DNS-Resolver Software für kleine Netzwerke, und nannte diese kumulativ “DnSpooq".<a id="fnref1" class="footnote-ref" href="#fn1"><sup>1</sup></a></p>
<figure><img src="https://cert.at/media/files/news/blog/20210527/dnsmasq-highest-versions.png" alt="Häufigste dnsmasq Versionen in AT (Stand 2021-01)" width="100%" />
<figcaption>Häufigste <code>dnsmasq</code> Versionen in AT (Stand 2021-01)</figcaption>
<figcaption></figcaption>
<figcaption></figcaption>
<figcaption></figcaption>
</figure>
<p>CERT.at suchte daraufhin via <a href="https://www.shodan.io">Shodan</a> nach <code>dnsmasq</code> Installationen und deren Versionen in Österreich – die Ergebnisse haben wir <a href="https://cert.at/de/aktuelles/2021/1/dnspooq-wie-sehr-spukts-in-osterreich">in einem Blogpost festgehalten</a> und eine kurze Übersicht zu den häufigsten Versionen ist in der Abbildung oben zu sehen.</p>
<p>Wir kontaktierten alle BetreiberInnen potentiell verwundbarer Installationen. Ein erneuter Scan, um festzustellen, wieviel sich bisher verändert hat, ist noch ausständig.</p>
<h3 id="emotet">Emotet-Takedown und die Folgen</h3>
<p><a href="https://malpedia.caad.fkie.fraunhofer.de/details/win.emotet">Emotet</a> war für mehrere Jahre eine der gefährlichsten Malware-Arten; die Software wurde immer wieder mit neuen Features versehen und obwohl sie als Banking-Trojaner gestartet war, fand sie im späteren Verlauf ihrer Entwicklung vor allem als “Stager" Verwendung, d.h. Schadsoftware, die dazu genutzt wird, um andere Malware nachzuladen. Als solcher war Emotet beispielsweise bei diversen Ransomware-Gruppen beliebt.</p>
<p>Aber damit war Ende Jänner 2021 Schluss: Behörden aus Deutschland, den Niederlanden, UK, Litauen, Frankreich, der Ukraine, Kanada und den USA ist es in Zusammenarbeit mit Europol und Eurojust gelungen, die Infrastruktur hinter Emotet zu übernehmen<a id="fnref2" class="footnote-ref" href="#fn2"><sup>2</sup></a> und die Malware damit effektiv auszuschalten. Dass diese Aktion ein so durchschlagender Erfolg wurde, ist keine Selbstverständlichkeit, wie nur wenige Monate zuvor der missglückte Takedown-Versuch gegen Trickbot gezeigt hatte.<a id="fnref3" class="footnote-ref" href="#fn3"><sup>3</sup></a></p>
<p>Im Zuge dieser Operation erlangten die ErmittlerInnen auch Zugriff auf zahlreiche Datenbanken der Kriminellen hinter Emotet und werteten sie aus. Dabei kamen unter anderem Informationen zu potentiell sämtlichen Opfern Emotets zu Tage, die an die jeweils zuständigen nationalen CERTs/CSIRTs weitergeleitet wurden – auf diesem Weg erhielt CERT.at entsprechend die Daten für Österreich.</p>
<p>Obwohl diese teilweise mehrere Jahre alt waren, kontaktierten wir alle potentiellen Opfer bzw. die jeweiligen BetreiberInnen der Plattformen, zu denen Login-Daten gestohlen worden waren, damit diese ihre KundInnen informieren konnten. Insgesamt erstellten wir im Jänner und Februar 14 Aussendungen zu Emotet mit mehreren zehntausend Betroffenen.</p>
<p>Abschließend ist anzumerken, dass die Behörden die Emotet-Malware so veränderten, dass sie sich am 25. April 2021 selbst deinstalliert hat und diese langjährige Bedrohung damit endgültig ein Ende gefunden hat. Leider ist aber davon auszugehen, dass die Kriminellen hinter Emotet mit ihrer Erfahrung und genügend Zeit ihre Infrastruktur mit neuer Schadsoftware wieder aufbauen können, oder dass andere Malware Emotets Platz einnimmt – von einem merklichen Rückgang der Cyber-Kriminalität ist jedenfalls auch nach Emotets Verschwinden nichts zu bemerken.</p>
<h3 id="ms-exchange">Microsoft Exchange Notfallpatches</h3>
<p>Während mit CVE-2019-19781 a.k.a. “Shitrix" das Jahr 2020 direkt mit einer großflächig ausgenutzten Lücke begonnen hatte, ließ sich 2021 ein bisschen mehr Zeit, um dann aber wirklich alle Register zu ziehen: Anfang März wurden Notfallpatches für Microsoft Exchange, also Microsofts E-Mail-Server, veröffentlicht und die hatten es in sich: AngreiferInnen konnten durch die Kombination mehrerer Schwachstellen ohne jegliche Authentifizierung beliebigen Code als <code>NT Authority\SYSTEM</code> auf ungepachten Servern ausführen.</p>
<p>Aber damit nicht genug; diese Lücken wurden zum Zeitpunkt der Patch-Veröffentlichung bereits von mindestens einer Gruppe großflächig ausgenutzt, d.h. selbst wenn ein Server sofort nach dem Erscheinen der Patches aktualisiert wurde, war nicht auszuschließen, dass er zuvor bereits kompromittiert worden war.</p>
<p>Microsoft veröffentlichte auch ein Script, mit dessen Hilfe verwundbare Installationen von außen identifiziert werden konnten. Dadurch war es uns möglich, schnell einen Scan für ganz Österreich zu erstellen und potentiell Betroffene zu informieren.</p>
<p>Bald wurde außerdem klar, dass viele AngreiferInnen Webshells auf kompromittierten Systemen hinterließen und einige Firmen und Organisationen machten sich daran, diese Webshells zu finden. Darunter war auch Shadowserver, die diese Informationen an nationale CERTs/CSIRTs weiterleiteten, um Opfer von erfolgreichen Attacken warnen zu können.<a id="fnref4" class="footnote-ref" href="#fn4"><sup>4</sup></a></p>
<figure>
<figcaption><img src="https://cert.at/media/files/news/blog/20210527/exchange.png" alt="" width="100%" /></figcaption>
<figcaption>Anzahl verwundbarer Exchange Installationen in AT</figcaption>
<figcaption></figcaption>
<figcaption></figcaption>
</figure>
<p>Insgesamt verschickte CERT.at im März und April 20 anlassbezogene Aussendungen zu ungepatchten oder kompromittierten Microsoft Exchange Installationen in Österreich. Wie die Abbildung zeigt, sind nach unseren Scans Mitte Mai noch etwa 100 Exchange Server in Österreich nicht gepatcht, wobei wir natürlich nicht wissen, wieviele davon Honeypots o.Ä. sind.</p>
<h3 id="silverfish">SilverFish APT</h3>
<p>Die IT-Sicherheitsfirma PRODAFT veröffentlichte im März einen Bericht zu einer Hacking-Gruppe, der sie den Namen “SilverFish" gegeben und auf deren Infrastruktur sie Zugriff erlangt hatten. Die AngreiferInnen arbeiteten nach den dort gefundenen Informationen in mehreren Teams und hatten geregelte Arbeitszeiten, was für eine hohe Professionalisierung spricht – leider nichts Ungewöhnliches bei kriminellen Gruppen im Cyber-Bereich. Der vollständige Bericht ist <a href="https://www.prodaft.com/m/uploads/SilverFish_TLPWHITE.pdf">hier als PDF</a> abrufbar.</p>
<p>Da PRODAFT bei Ihrer Arbeit auch eine Liste der Opfer erlangten, kontaktierten sie kurz vor der Veröffentlichung nationale CERTs/CSIRTs, in deren Ländern es Betroffene gab. Auf diesem Weg erhielt auch CERT.at die Liste mit den (wenigen) Opfern in Österreich und kontaktierte diese umgehend.</p>
<h3 id="pulse-connect-secure">Pulse Connect Secure</h3>
<p>Da die Anzahl von Unauthenticated RCEs in kritischer Software, die bei der Veröffentlichung von Updates oder Workarounds bereits aktiv ausgenutzt werden, in den ersten vier Monaten von 2021 eindeutig noch zu niedrig war, sorgte <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-22893">CVE-2021-22893</a> für Nachschub. Diese betraf Pulse Connect Secure, einer VPN Software der Firma Ivanti. Am 2021-04-20 wurden Workarounds veröffentlicht, “echte" Updates kamen allerdings erst rund zwei Wochen später.</p>
<p>CERT.at erhielt eine Liste von Pulse Connect Secure Installationen in Österreich und kontaktierte die BetreiberInnen mit der Bitte, die Workarounds möglichst schnell einzuspielen.</p>
<h3 id="sonicwall-email-security">SonicWall Email Security</h3>
<p>Am selben Tag, an dem Workarounds zur Schwachstelle in Pulse Secure Connect veröffentlicht wurden, gab auch SonicWall bekannt, dass es in einigen Versionen von SonicWall Email Security schwerwiegende Sicherheitslücken gibt, die in Kombination zur vollständigen Übernahme des Systems führen können und bereits aktiv ausgenutzt werden. Hier kam allerdings der mildernde Umstand hinzu, dass für den initialen Exploit ein administratives Web-Interface aus dem offenen Internet erreichbar sein muss, was für die Funktionalität der Software nicht notwendig ist.</p>
<p>FireEye erwähnt in <a href="https://www.fireeye.com/blog/threat-research/2021/04/zero-day-exploits-in-sonicwall-email-security-lead-to-compromise.html">einem Blogpost dazu</a>, dass sie bei einem Internet-weiten Scan etwa 700 Installationen gefunden hatten, bei denen dieses Interface erreichbar war. CERT.at erhielt eine Liste der betroffenen Instanzen in Österreich und kontaktierte die BetreiberInnen.</p>
<h2 id="projekte-konferenzen">Projekte und Konferenzen</h2>
<h3 id="melicertes">MeliCERTes 2 (SMART-2018-2014)</h3>
<p>In den ersten vier Monaten des Jahres floss die meiste Arbeit in das Identifizieren und Bewerten von Single-Sign-On Lösungen, da im Zuge des Projekts eine solche für das gesamte <a href="https://csirtsnetwork.eu/">CSIRTs Network (CNW)</a> gefunden und implementiert werden soll.</p>
<p>Dazu mussten initial die Bedürfnisse des CNW genau erfasst werden, um sicherzustellen, dass die sich daraus ergebenden Anforderungen auch erfüllt werden können. Dazu fanden mehrere (virtuelle) Treffen statt, deren Ergebnisse verschriftlicht wurden.</p>
<p>Das Ziel ist es, eine SSO Lösung zu schaffen, mit der sich MitarbeiterInnen sämtlicher Organisationen des CNW bei den zentralen Services anmelden können sowie bei Bedarf auch bei solchen, die andere Mitglieder des CNW lokal betreiben werden und für die Partner öffnen. Aktuell werden die zentralen Services teils von der ENISA, aber auch von Teams im CNW bereitgestellt. Außerdem wurde im April der erste Workshop zu <a href="https://github.com/certtools/intelmq">IntelMQ</a> für Angehörige des CNW durchgeführt.</p>
<p>Allgemeine Projektinformationen finden Sie <a href="https://cert.at/de/ueber-uns/projekte/#melicertes-smart-2018-2014">auf unserer Webseite</a>.</p>
<h3 id="cef-2018">“Enhancing Cybersecurity in Austria" (2018-AT-IA-0111)</h3>
<h4 id="international-engagement">International Engagement</h4>
<p>Im Jänner 2021 fand das 62. TF-CSIRT Meeting virtuell statt, an dem Sebastian Wagner und Benedikt Olszewski für CERT.at teilnahmen.</p>
<p>Ebenfalls im Jänner 2021 nahm Thomas Pribitzer aus dem Handler Team an einem virtuellen TRANSITS I Training teil. <a href="https://www.geant.org/Services/Trust_identity_and_security/Pages/TRANSITS_Training.aspx">TRANSITS-Trainings</a> richten sich speziell an CERT/CSIRT MitarbeiterInnen und dienen dem Austausch und der Vernetzung in diesem Bereich.</p>
<p>Nach der Absolvierung eines SANS SEC504 Trainings Ende des Vorjahres bestand Thomas Pribitzer im Februar die Prüfung zum <a href="https://www.giac.org/certification/certified-incident-handler-gcih">GIAC Certified Incident Handler (GCIH)</a>, wir gratulieren.</p>
<p>Im Februar 2021 hielten Sebastian Wagner und Birger Schacht einen Vortrag zum Thema IntelMQ auf dem virtuellen <a href="https://www.enisa.europa.eu/topics/csirt-cert-services/community-projects/incident-handling-automation">IHAP</a> Meeting.</p>
<p>Am 13. CNW Meeting, das im März 2021 virtuell stattfand, nahmen Otmar Lendl und Wolfgang Rosenkranz für CERT.at teil.</p>
<h4 id="tooling">Tooling</h4>
<p>Im Februar 2021 veröffentlichten wir gemeinsam mit der R&D Abteilung der Nic.at das Open Source Tool <a href="https://github.com/nic-at/openintel-lookup">OpenINTEL-lookup</a>: Dabei handelt es sich um ein User Interface und eine API, um Daten von OpenINTEL abzufragen.</p>
<p><a href="https://www.openintel.nl/">OpenINTEL</a> ist ein Projekt der <a href="https://www.utwente.nl/en">Universität Twente</a> in Zusammenarbeit mit <a href="https://www.surf.nl/">SURFnet</a>, <a href="https://www.sidnlabs.nl/en">SIDN Labs</a> und <a href="https://www.nlnetlabs.nl/">NLnet Labs</a>. Ziel ist es, sämtliche DNS-Einträge aller teilnehmenden DNS-Zonen aktiv abzufragen, um eine qualitativ hochwertige Datenbasis zu erstellen, die den Zustand des DNS-Systems im Laufe der Zeit erfasst.</p>
<p>Anfang März veröffentlichten wir IntelMQ 2.3.0 inklusive dazugehöriger Tools wie dem IntelMQ Manager und der neuen IntelMQ API.</p>
<p>Es war auch das erste Release mit einem Docker Image verfügbar auf Dockerhub unter <a href="https://hub.docker.com/r/certat/intelmq-full">certat/intelmq-full</a>. Details zu allen Neuerungen finden Sie <a href="https://cert.at/en/blog/2021/3/intelmq-230-api-docker-shadowserver-reports-api-documentation">im dazugehörigen Blogpost</a>.</p>
<p>Im April wurde mit <a href="https://github.com/certtools/intelmq/releases/tag/2.3.2">IntelMQ 2.3.2</a> das letzte Maintenance Release für das erste Drittel 2021 veröffentlicht, welches Bugfixes sowie Verbessungen für Shadowserver and Shodan enthielt.</p>
<p>Im gleichen Monat gab es einige Neuerungen bei <a href="https://github.com/nic-at/tag2domain">tag2domain</a> im Zusammenhang mit flexibleren Taxonomien. Ausführliche Beschreibungen finden sich <a href="https://cert.at/en/blog/2021/4/flexible-taxonomies-and-new-software-for-the-tag2domain-project">in unserem Blog Post</a>.</p>
<h3 id="vortraege">Vorträge</h3>
<ul>
<li>
<p>Im Jänner 2021 hielt Dimitri Robl von CERT.at im Rahmen der Vorlesung "Netzwerktechnologien" an der Universität Wien einen Gastvortrag. Dabei wurden die Aufgaben von CERT.at und CERTs/CSIRTs generell vorgestellt sowie einige Beispiele für netzwerkbezogene Schwachstellen und Angriffe mit den Studierenden besprochen.</p>
</li>
<li>
<p>Am 23. April fand das erste Treffen der Cyber Sicherheit Plattform von 2021 statt. Die Cyber Sicherheit Plattform hat den Zweck, VertreterInnen von Verwaltung, Wirtschaft und Wissenschaft zu einem regelmäßigen Informationsaustausch und zur Vorstellung aktueller Themen zusammenzubringen. In der Regel finden dazu seit 2015 jedes Jahr zwei Veranstaltungen statt, seit Beginn der Pandemie natürlich virtuell. Neben rechtlichen und technischen Themen wurden durch Wolfgang Rosenkranz von CERT.at aktuelle Entwicklungen im Themenkomplex der Cybersecurity-Fachkräfteausbildung vorgestellt. Eine interessante Entwicklung sind beispielsweise die Arbeiten der ENISA zur Anpassung des <a href="https://www.nist.gov/itl/applied-cybersecurity/nice">“Workforce Framework for Cybersecurity" (NICE Framework) von NIST</a>, dessen Bausteine eine bessere Definition und Vergleichbarkeit von Rollen, Aufgaben und Fähigkeiten von Personen, die im Cybersecurity-Bereich arbeiten, ermöglichen sollen.</p>
</li>
</ul>
<section class="footnotes"><hr />
<ol>
<li id="fn1">
<p>Nähere Informationen dazu finden sich <a href="https://www.jsof-tech.com/disclosures/dnspooq/">im Blogpost von JSOF</a>.<a class="footnote-back" href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Siehe dazu die <a href="https://www.europol.europa.eu/newsroom/news/world%E2%80%99s-most-dangerous-malware-emotet-disrupted-through-global-action">Pressemitteilung von Europol</a>.<a class="footnote-back" href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>Mehr Informationen dazu finden Sie z.B. <a href="https://www.bleepingcomputer.com/news/security/trickbot-botnet-targeted-in-takedown-operations-little-impact-seen/">hier</a>.<a class="footnote-back" href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>Siehe dazu <a href="https://www.shadowserver.org/news/shadowserver-special-report-exchange-scanning-5/">Shadowservers Blogpost</a>, in dem auch auf alle ihre Aktivitäten in Bezug auf die Exchange-Schwachstellen verlinkt wird.<a class="footnote-back" href="#fnref4">↩</a></p>
</li>
</ol>
</section>CERT.at2021-05-27T08:00:00ZRückblick auf das letzte Drittel 2020CERT.at2021-01-25T07:57:18Z2021-01-25T08:00:00Z<ul>
<li class="block"><a href="#september">September</a></li>
<li class="block"><a href="#oktober">Oktober</a></li>
<li class="block"><a href="#november">November</a></li>
<li class="block"><a href="#dezember">Dezember</a></li>
</ul>
<h2 id="september" class="block">September</h2>
<h3 class="block">Vorfälle und Aussendungen</h3>
<h4 class="block">ZeroLogon</h4>
<p class="block"><a title="https://nvd.nist.gov/vuln/detail/CVE-2020-1472" href="https://nvd.nist.gov/vuln/detail/CVE-2020-1472">CVE-2020-1472</a> a.k.a. ZeroLogon ist eine Schwachstelle in Microsofts Remote Netlogon Protokoll, die vor allem für die Post-Exploitation-Phase eines Angriffs nützlich ist. Mithilfe von ZeroLogon kann das Computerpasswort eines beliebigen Computers in der Active Directory Domäne auf ein leeres Passwort gesetzt werden. AngreiferInnen können z.B. das Computerpasswort des Domain-Controllers löschen und sich dann mit dem Computer-Account, der über weitreichende Rechte verfügt, anmelden und die <code>ntds.dit</code>-Datei, die unter anderem die gehashten Passwörter aller Accounts in der Domäne enthält, stehlen.</p>
<p class="block"><a title="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1472" href="https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-1472">Ein erster Patch</a>, um diese Schwachstelle zu beheben, wurde zwar bereits im Zuge von Microsofts Patchday im August veröffentlicht, allerdings gab Microsoft an, dass dieser nicht sämtliche Angriffsszenarien abdeckte und vertröstete auf einen vollständigen Patch im Februar 2021.</p>
<p class="block">Exploits für die Lücke ließen allerdings nicht so lange auf sich warten und bereits Mitte September waren mehrere auf GitHub verfügbar.</p>
<p class="block">CERT.at bekam von einer externen Quelle eine Liste von potentiell verwundbaren Servern in Österreich und kontaktierte die Betroffenen. Außerdem berichteten wir zweimal in unseres Kategorie "Aktuelles" über die Entwicklungen.<a id="fnref1" href="#fn1"><sup>1</sup></a></p>
<h4 class="block">Emotet</h4>
<p class="block">Nicht fehlen durfte natürlich auch im September Emotet, zu dem wir ebenfalls eine Aussendung machten.</p>
<h3 class="block">Projekte und Konferenzen</h3>
<h4 class="block">Shodan Verified Vulnerabilities</h4>
<p class="block">Im September 2020 haben wir damit begonnen, einmal pro Monat Statistiken zu jenen Schwachstellen zu veröffentlichen, die <a title="https://www.shodan.io/" href="https://www.shodan.io/">Shodan</a> in Österreich findet und die jeweiligen Entwicklungen dabei zu verfolgen.<a id="fnref2" class="footnote" href="#fn2"><sup>2</sup></a> Bislang hat sich herausgestellt, dass SSL/TLS-Schwachstellen die Liste mit großem Vorsprung anführen und das Gesamtbild insgesamt relativ stabil ist. Ersteres kann aber dem Umstand geschuldet sein, dass solche Lücken leichter von außen zu verifizieren sind.</p>
<h2 id="oktober" class="block">Oktober</h2>
<h3 class="block">Vorfälle und Aussendungen</h3>
<p class="block">Insgesamt stand der Oktober, was Aussendungen anging, im Zeichen der Untoten – konkret ging es um stark veraltete Windows Versionen sowie eine ältere Exchange-Schwachstelle.</p>
<h4 class="block">Microsoft Exchange CVE-2020-0688</h4>
<p class="block">Diese bereits im Zuge des Microsoft Patchday im Februar 2020 geschlossene Lücke ermöglicht RCE mit <code>NT Authority\SYSTEM</code> Rechten, sofern die AngreiferInnen die Zugangsdaten für einen beliebigen Mailaccount kennen. Wir hatten im April 2020 nach ungepatchten Systemen in Österreich gesucht und die Betroffenen informiert,<a id="fnref3" class="footnote" href="#fn3"><sup>3</sup></a> aber da das deutsche BSI (Bundesamt für Sicherheit in der Informationstechnik) im Oktober in einer Presseaussendung verlautbarte, dass das Update im Deutschland nach wie vor vielfach nicht eingespielt worden war, wollten wir noch einmal einen Blick auf die Situation in Österreich werfen. Das ernüchternde Ergebnis: Auch in Österreich hat sich seit April kaum etwas geändert.<a id="fnref4" class="footnote" href="#fn4"><sup>4</sup></a></p>
<p class="block">Dementsprechend informierten wir wiederum die Betroffenen. Ein weiterer Scan im ersten Drittel 2021 ist ebenfalls geplant.</p>
<h4 class="block">Windows Server ohne Support</h4>
<p class="block">Rapid7 veröffentlichte im Oktober einen <a title="https://blog.rapid7.com/2020/10/19/are-you-still-running-end-of-life-windows-servers/" href="https://blog.rapid7.com/2020/10/19/are-you-still-running-end-of-life-windows-servers/">Blogpost</a>, laut dem weltweit über 50% der öffentlich erreichbaren Windows Server Instanzen auf nicht mehr unterstützten Versionen (Windows Server 2008 R2 und darunter) laufen. Wir haben uns daraufhin die <a title="https://cert.at/de/aktuelles/2020/10/microsoft-end-of-life-produkte-in-at" href="https://cert.at/de/aktuelles/2020/10/microsoft-end-of-life-produkte-in-at">Situation in Österreich</a> angesehen und festgestellt, dass sie zwar etwas, aber nicht viel besser ist.</p>
<p class="block">Jedenfalls haben wir die Betroffenen informiert und ihnen dringend zum Updaten geraten. Auch hier ist noch eine Wiederholung des Scans ausständig, die wir im ersten Drittel 2021 durchführen werden.</p>
<h4 class="block">Ungepatchte Sophos Firewall XG Instanzen</h4>
<p class="block">Im Juli 2020 hatte Sophos eine schwere Lücke in ihrem Firewall XG Produkt geschlossen. Dabei handelte es sich um eine SQL Injection Schwachstelle, die in weiterer Folge potentiell zu einer Remote Code Execution (RCE) führen konnte. Obwohl Firewall XG per Default so eingestellt ist, dass neue Updates automatisch eingespielt werden, dürfte diese Feature vielfach deaktiviert worden sein, denn wir erhielten im Oktober eine Liste nach wie vor anfälliger Instanzen in Österreich und informierten umgehend die BetreiberInnen.</p>
<h4 class="block">SonicOS DoS und RCE</h4>
<p class="block">In der ersten Oktoberhälfte wurde eine Buffer Overflow Schwachstelle in SonicOS bekannt (<a title="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5135" href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5135">CVE-2020-5135</a>), über die ein Denial of Service Angriff durchgeführt werden konnte. Zusätzlich bestand lt. <a title="https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010" href="https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2020-0010">Advisory</a> auch die Gefahr, dass diese zu einer RCE ausgebaut werden konnte. Da das Problem im HTTP/HTTPS-Service liegt und dieser unter anderem für den Aufbau von SSL VPN Verbindungen zuständig ist, sind diese Geräte im Normalfall aus dem offenen Internet erreichbar.</p>
<p class="block">CERT.at suchte via Shodan nach Instanzen in Österreich und informierte die Betroffenen.</p>
<h3 class="block">Projekte und Konferenzen</h3>
<h4 class="block">IT-Security Stammtisch goes online</h4>
<p class="block">Nach einer längeren Pause unseres sonst monatlich durchgeführten IT-Security Stammtisches, haben wir ihn im Oktober 2020 erstmals online durchgeführt. Als großer Vorteil der virtuellen Variante hat sich v.a. die wesentlich breitere Teilnahme von Personen außerhalb (Nord-)Ost-Österreichs herausgestellt, weshalb wir überlegen, auch nach COVID-19 eine Remote-Teilnahme zu ermöglichen.</p>
<h4 class="block">Neue Mitarbeiter für MeliCERTes 2</h4>
<p class="block">Über das MeliCERTes 2 Projekt konnten ab 1. Oktober mit Sebastian Waldbauer und Birger Schacht zwei neue Mitarbeiter finanziert werden, die sich vornehmlich um die Betreuung und Weiterentwicklung von <a title="https://github.com/certtools/intelmq" href="https://github.com/certtools/intelmq">IntelMQ</a> kümmern.</p>
<h4 class="block">“Enhancing Cybersecurity in Austria” (2018-AT-IA-0111)</h4>
<p class="block">Im Zuge dieses CEF (Connecting Europe Facilities) Projekts wurde im Oktober die Entwicklung eines neuen Constituency-Portals gestartet, um unsere Kontaktadressen besser zu verwalten (siehe Blogpost auf <a title="https://cert.at/de/blog/2020/10/neuentwicklung-des-constituency-portals" href="https://cert.at/de/blog/2020/10/neuentwicklung-des-constituency-portals">Deutsch</a> und <a title="https://cert.at/en/blog/2020/10/development-of-the-constituency-portal-20" href="https://cert.at/en/blog/2020/10/development-of-the-constituency-portal-20">Englisch</a>).</p>
<p class="block">Außerdem erschien mit <a title="https://lists.cert.at/pipermail/intelmq-users/2020-October/000178.html" href="https://lists.cert.at/pipermail/intelmq-users/2020-October/000178.html">IntelMQ 2.2.2</a> ein Release, der einige Fehler korrigierte.</p>
<h2 id="november" class="block">November</h2>
<h3 class="block">Vorfälle und Aussendungen</h3>
<h4 class="block">cit0day Leak</h4>
<p class="block">Anfang November wurde ein großer Leak bekannt: Die Plattform cit0day[.]in, auf der (vornehmlich) Kriminelle andere Leaks kaufen konnten wurde im September 2020 vom Netz genommen. Angezeigt wurde ein Banner, das behauptete, die Seite sei von der amerikanischen Exekutive beschlagnahmt worden, allerdings wurde dies nie bestätigt und es kam auch zu keinen öffentlich bekannten Festnahmen in diesem Zusammenhang, weshalb die Vermutung naheliegt, dass der Takedown von den Verantwortlichen hinter der Plattform selbst inszeniert war.<a id="fnref5" class="footnote" href="#fn5"><sup>5</sup></a></p>
<p class="block">Wie dem auch sei, im November wurden das Leak-Archive von cit0day[.]in auf der File-Sharing-Plattform MEGA öffentlich verfügbar gemacht. Etwas später erschienen die Daten noch einmal in einem anderen Format.</p>
<p class="block">Wir konnten die Daten aller betroffenen <code>gv.at</code> Adressen feststellen und informierten die jeweiligen MX-BetreiberInnen. Aus den Rückmeldungen ergab sich, dass die gestohlenen Daten zum Großteil schon ziemlich alt (z.T. mehr als zehn Jahre) waren, also kaum eine unmittelbare und große Gefahr darstellten.</p>
<h4 class="block">Alte und neue CVEs</h4>
<p class="block">Im November erhielten wir Informationen zur Verbreitung einiger CVEs in Österreich und informierten Betroffene von <a title="https://nvd.nist.gov/vuln/detail/CVE-2014-3398" href="https://nvd.nist.gov/vuln/detail/CVE-2014-3398">CVE-2014-3398</a> (Cisco ASA), <a title="https://nvd.nist.gov/vuln/detail/CVE-2019-1653" href="https://nvd.nist.gov/vuln/detail/CVE-2019-1653">CVE-2019-1653</a> (Cisco RV320/RV325 Router) und <a title="https://nvd.nist.gov/vuln/detail/CVE-2020-3452" href="https://nvd.nist.gov/vuln/detail/CVE-2020-3452">CVE-2020-3452</a> (Cisco ASA und Cisco FTD).</p>
<h3 class="block">Projekte und Konferenzen</h3>
<p class="block">Im November nahm L. Aaron Kaplan, Mitarbeiter #4 bei CERT.at, Abschied und machte sich zu neuen Herausforderungen auf, für die wir ihm alles Gute wünschen.</p>
<p class="block">Außerdem bekam CERT.at in diesem Monat mit Wolfgang Rosenkranz einen neuen Teamleiter. Otmar Lendl, der diese Funktion seit der Gründung innehatte, kann sich nun voll auf die nationale und internationale Vernetzung konzentrieren.</p>
<h4 class="block">“Enhancing Cybersecurity in Austria” (2018-AT-IA-0111)</h4>
<p class="block">IntelMQs Dokumentation zog in diesem Monat auf <a title="https://intelmq.readthedocs.io/" href="https://intelmq.readthedocs.io/">intelmq.readthedocs.io</a> (und damit auf <a title="https://www.sphinx-doc.org/" href="https://www.sphinx-doc.org/">Sphinx</a>) um, und erhielt dadurch einige neue Features.</p>
<h2 id="dezember" class="block">Dezember</h2>
<h3 class="block">Vorfälle und Aussendungen</h3>
<h4 class="block">Ein Leak kommt selten allein</h4>
<p class="block">Kaum war der Cit0day-Leak vom November verarbeitet, tauchte ein neuer auf: Diesmal waren Zugangsdaten zu VPN-Servern von FortiOS betroffen. Es dürfte sich dabei um Daten handeln, die mithilfe einer im Mai 2020 geschlossenen Lücke gestohlen wurden. Auch hier wurden die Patches leider vielfach nicht eingespielt, obwohl seit August 2020 öffentliche Exploits verfügbar waren.<a id="fnref6" class="footnote" href="#fn6"><sup>6</sup></a></p>
<p class="block">Der Leak wurde zwar bereits Ende November bekannt, wir erhielten die relevanten Daten allerdings erst Anfang Dezember und informierten die Betroffenen dann so schnell wie möglich.</p>
<h4 class="block">D-Link Router unauthenticated RCE</h4>
<p class="block">D-Link veröffentliche Anfang Dezember ein <a title="https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10195" href="https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10195">Advisory zu einer Reihe von Schwachstellen</a>, deren schlimmste wohl CVE-2020-25757, eine unauthenticated RCE mit Root-Rechten, ist. Diese betrafen mehrere Router-Modelle, von denen einige bereits nicht mehr unterstützt wurden und daher auch keine Updates erhielten.</p>
<p class="block">Mithilfe von <a title="https://www.shodan.io/" href="https://www.shodan.io/">Shodan</a> konnten wir betroffene Geräte identifizieren und informierten deren BetreiberInnen.</p>
<h4 class="block">SolarWinds Orion</h4>
<p class="block">Am 12. Dezember veröffentlichte FireEye einen Blogpost über einen erfolgreichen Angriff auf ihre Infrastruktur, bei dem interne Red-Teaming Tools gestohlen worden waren. Zwei Tage später folgte ein weiterer Blogpost, der den initialen Angriffsvektor bekanntgab: SolarWinds Orion, eine IT-Infrastruktur Management Software. Es stellte sich heraus, dass eine hochprofessionelle, mit hoher Wahrscheinlichkeit staatlich finanzierte Gruppe, in die Produktivsysteme von SolarWinds eingedrungen war und es geschafft hatte, Hintertüren in den Code der Orion Software einzubauen, die über einen Zeitraum von sechs Monaten in allen Updates ausgeliefert wurden. Eingespielt hatten diese "Updates" etwa 18000 KundInnen von SolarWinds – bei wievielen davon die AngreiferInnen im Anschluss auch tatsächlich aktiv wurden, ist nach wie vor unklar und auch die Untersuchungen zu den verwendeten TTPs (Tactics, Techniques, and Procedures) dauern noch an. Eine laufend aktualisierte Liste der Ereignisse und dazu veröffentlichter Artikel findet sich in einem <a title="https://www.dropbox.com/s/yu5uwsfyo9q4oj2/Whitepaper%20SolarWinds%20Orion%20Supply-chain%20Attack.pdf?dl=0" href="https://www.dropbox.com/s/yu5uwsfyo9q4oj2/Whitepaper%20SolarWinds%20Orion%20Supply-chain%20Attack.pdf?dl=0">Whitepaper des ThaiCERTs</a>.</p>
<p class="block">Natürlich setzten auch wir uns mit dem Thema auseinander, Hinweise zu Angriffszielen in Österreich gab es jedoch keine.</p>
<h3 class="block">Projekte und Konferenzen</h3>
<h4 class="block"> MeliCERTes 2</h4>
<p class="block">Im Rahmen des <a title="https://cert.at/de/ueber-uns/projekte/#melicertes-smart-2018-2014" href="https://cert.at/de/ueber-uns/projekte/#melicertes-smart-2018-2014">MeliCERTes 2 Projektes</a> wurde im Herbst 2020 die Erhebung der Anforderungen an den Werkzeugkasten der CERT und des CSIRTs Networks finalisiert. Die Hauptpunkte sind:</p>
<ul>
<li class="block">Die bestehenden zentralen Services sollen ein gemeinsames Identity and Access Management (IAM) System erhalten, das durch ein Verzeichnis der Teams und deren MitarbeiterInnen provisioniert wird.<br />Die Rolle des Directories soll <a title="https://github.com/cerebrate-project/cerebrate" href="https://github.com/cerebrate-project/cerebrate">Cerebrate</a> übernehmen, eine Open Source Lösung, die von <a title="https://circl.lu/" href="https://circl.lu/">CIRCL</a>, dem nationalen CERT von Luxemburg, entwickelt wird. Welche Software als Identity Provider fungieren wird, und wie der Übergang zur neuen Lösung aussehen soll, wird aktuell in enger Kooperation mit der <a title="https://www.enisa.europa.eu/" href="https://www.enisa.europa.eu/">ENISA</a> ausgearbeitet.</li>
<li class="block">In Bezug auf Videokonferenzen für das <a title="https://www.enisa.europa.eu/topics/csirts-in-europe/csirts-network" href="https://www.enisa.europa.eu/topics/csirts-in-europe/csirts-network">CSIRTs Network</a> wurde gemeinsam mit der ENISA eine Studie erstellt, die die Features der verfügbaren Lösungen den Anforderungen einiger Nutzungsszenarien gegenüberstellt. Die Veröffentlichung einer <a title="https://www.first.org/tlp/" href="https://www.first.org/tlp/">[TLP:WHITE]</a> Version dieser Untersuchung soll demnächst erfolgen.</li>
<li class="block">Weiters wurde erhoben, welche Tools sinnvollerweise Teil des MeliCERTes Projektes sein könnten, und wie diese (im Falle von lokal eingesetzten) am besten an die einzelnen Teams verteilt werden, damit sie sich gut in deren lokale IT Landschaft einfügen.</li>
</ul>
<p class="block">Neben diesem Requirements-Prozess wurde auch an <a title="https://github.com/certtools/intelmq" href="https://github.com/certtools/intelmq">IntelMQ</a> gearbeitet: Die Paketierung wurde verbessert und der erste Release als Docker-Image zur Verfügung gestellt.</p>
<h4 class="block">“Enhancing Cybersecurity in Austria” (2018-AT-IA-0111)</h4>
<p class="block">Im Dezember fand ein (virtuelles) CSIRTs Network Meeting statt, an dem Otmar Lendl, Wolfgang Rosenkranz und Sebastian Wagner teilnahmen. Im Zuge des Treffens gab es auch eine "Capture the Flag" (CTF) Herausforderung bei der zwei Teams den ersten Platz belegten, wobei Otmar Lendl im einen und Sebastian Wagner im anderen war.</p>
<p class="block">Mit <a title="https://lists.cert.at/pipermail/intelmq-users/2020-December/000187.html" href="https://lists.cert.at/pipermail/intelmq-users/2020-December/000187.html">IntelMQ 2.2.3</a> gab es einen weiteren Bug-Fix Release und in diesem Monat erschien erstmals <a title="https://lists.cert.at/pipermail/intelmq-users/2020-December/000186.html" href="https://lists.cert.at/pipermail/intelmq-users/2020-December/000186.html">ein rpm Paket</a> zur einfachen Installation auf CentOS 8.</p>
<p class="block">Außerdem wurde die Entwicklung von IntelMQ 3.0 fortgesetzt. Dazu gab es einen auf UserInnenfeedback basierenden, ersten großen <a title="https://lists.cert.at/pipermail/intelmq-users/2020-December/000185.html" href="https://lists.cert.at/pipermail/intelmq-users/2020-December/000185.html">Änderungsvorschlag bei der Konfiguration</a>.</p>
<section class="footnotes"><hr />
<ol>
<li id="fn1">
<p>Siehe <a href="https://cert.at/de/aktuelles/2020/9/domain-controller-ubernahme-aus-dem-internen-netz-mehr-details-zu-cve-2020-1472">https://cert.at/de/aktuelles/2020/9/domain-controller-ubernahme-aus-dem-internen-netz-mehr-details-zu-cve-2020-1472</a> und <a href="https://cert.at/de/aktuelles/2020/9/neues-zur-zerologon-sicherheitslucke-cve-2020-1472">https://cert.at/de/aktuelles/2020/9/neues-zur-zerologon-sicherheitslucke-cve-2020-1472</a>. <a class="footnote-back" href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Siehe dazu unseren <a title="https://cert.at/de/blog/2020/9/shodan-verified-vulnerabilities-statistiken-zu-schwachstellen-in-osterreich" href="https://cert.at/de/blog/2020/9/shodan-verified-vulnerabilities-statistiken-zu-schwachstellen-in-osterreich">initialen Blogbeitrag</a>, sowie die Einträge zu <a title="https://cert.at/de/aktuelles/2020/10/shodan-verified-vulns-2020-10-05" href="https://cert.at/de/aktuelles/2020/10/shodan-verified-vulns-2020-10-05">Oktober</a>, <a title="https://cert.at/de/aktuelles/2020/11/shodan-verified-vulns-2020-11-03" href="https://cert.at/de/aktuelles/2020/11/shodan-verified-vulns-2020-11-03">November</a> und <a title="https://cert.at/de/aktuelles/2020/12/shodan-verified-vulns-2020-12" href="https://cert.at/de/aktuelles/2020/12/shodan-verified-vulns-2020-12">Dezember</a> 2020.<a class="footnote-back" href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>Siehe <a href="https://cert.at/de/blog/2020/4/cve-2020-0688-verwundbare-microsoft-exchange-server-in-osterreich">https://cert.at/de/blog/2020/4/cve-2020-0688-verwundbare-microsoft-exchange-server-in-osterreich</a> <a class="footnote-back" href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>Siehe <a href="https://cert.at/de/aktuelles/2020/10/microsoft-exchange-cve-2020-0688-revisited">https://cert.at/de/aktuelles/2020/10/microsoft-exchange-cve-2020-0688-revisited</a> <a class="footnote-back" href="#fnref4">↩</a></p>
</li>
<li id="fn5">
<p>Siehe z.B. <a href="https://www.zdnet.com/article/23600-hacked-databases-have-leaked-from-a-defunct-data-breach-index-site/">https://www.zdnet.com/article/23600-hacked-databases-have-leaked-from-a-defunct-data-breach-index-site/</a> <a class="footnote-back" href="#fnref5">↩</a></p>
</li>
<li id="fn6">
<p>Siehe z.B. <a href="https://heise.de/-4968392">https://heise.de/-4968392</a> <a class="footnote-back" href="#fnref6">↩</a></p>
</li>
</ol>
</section>CERT.at2021-01-25T08:00:00ZEin erster Blick auf NIS 2.0CERT.at2021-01-22T19:19:15Z2021-01-22T19:10:00Z<p class="block">Da auch die Kommission mein Feedback lesen können soll, hab ich das auf Englisch geschrieben:</p>
<p class="block"><a href="https://cert.at/en/blog/2021/1/nis2-recitals-feedback">A look at the NIS 2.0 Recitals</a></p>CERT.at2021-01-22T19:10:00ZAbuse.ch URLhaus als neue Datenquelle für unsere Aussendungen aufgenommenCERT.at2021-01-20T11:09:56Z2021-01-20T11:05:00Z<p class="block">Seit Mittwoch, 13. Jänner 2020 senden wir die Daten der <a href="https://urlhaus.abuse.ch/">URLhaus Feeds</a> des <a href="https://abuse.ch/">abuse.ch-Projekts</a> in unseren regelmäßigen Benachrichtigungen an Netzbetreiber aus. Die Feeds umfassen URLs, die Malwaredateien diverser Schadsoftwarefamilien hosten. Nach unseren Informationen sind die Daten der Quelle von sehr hoher Qualität, zusätzlich dazu verwenden wir nur die aktuellsten Daten. Feedback zu der neuen Datenquelle ist jederzeit gerne gesehen.</p>
<p class="block">Wie die Feeds zu einer <a href="https://intelmq.readthedocs.io/">IntelMQ</a>-Instanz hinzugefügt werden können, ist in <a href="https://intelmq.readthedocs.io/en/latest/user/feeds.html#urlhaus">IntelMQs Feed Dokumentation</a> beschrieben. Aufgrund interner Anforderungen haben wir außerdem einige zusätzliche Verarbeitungsschritte. In den folgenden Abschnitten beschreiben wir diese Verarbeitung.</p>
<p class="block">Wir haben zwei wesentliche Anforderungen, die für zusätzliche Komplexität sorgen:</p>
<ul>
<li class="block">Die Feeds beinhalten ein "Dateadded" Datenfeld, welches den Zeitpunkt angibt, an dem die Malware zum ersten Mal auf dieser URL verfügbar war (dieses Feld wird vom Parser "time.source" zugeordnet). Wir möchten aber, dass im "time.source" Feld der aktuellste Zeitpunkt steht, an dem die Malware unter der URL verfügbar war. Da die Daten des Feeds regelmäßig und in sehr kurzen Zeitintervallen auf Aktualität überprüft werden, kann die folgende Logik (in Pseudocode) angewendet werden: <code>time.source = time.observation - 1 hour</code>, wobei time.observation den Zeitpunkt beschreibt, an dem IntelMQ die Daten abgerufen hat. Daraus ergibt sich dann der Zeitpunkt, an dem die URL sicher aktiv war.</li>
<li class="block">Wir benützen sowohl den Country-feed als auch den TLD-feed. Da beide Feeds überlappende Daten enthalten, müssen wir diese deduplizieren.</li>
</ul>
<p class="block">Um die erste Anforderung zu erfüllen sind zwei Schritte notwendig, da sich diese Aufgabe aktuell nicht mit einem einzelnen IntelMQ Bot bewerkstelligen lässt. Zunächst setzen wir einen <a href="https://intelmq.readthedocs.io/en/latest/user/bots.html#modify">modify expert</a> mit der folgenden Konfiguration ein:</p>
<pre class="block">[
{
"rulename": "setze time.source auf time.observation",
"if": {},
"then": {
"time.source": "{msg[time.observation]}"
}
}
]</pre>
<p class="block">Darauf folgt ein <a href="https://intelmq.readthedocs.io/en/latest/user/bots.html#sieve">sieve expert</a>, mit folgenden Regeln:</p>
<pre class="block">if :exists time.source {<br /> add! time.source -= '1 hour'<br />}</pre>
<p class="block">Mathematische Operationen auf Datetime-Objekte werden ab dem kommenden IntelMQ Release 2.3.0 unterstützt.</p>
<p>Um die kombinierten Daten der Feeds für Country und TLD zu <a href="https://intelmq.readthedocs.io/en/latest/user/bots.html#deduplicator">deduplizieren</a>, nutzen wir folgende Einstellungen:</p>
<ul>
<li class="block"><code>filter_keys</code> ist gesetzt auf <code>raw,time.source,time.observation,feed.url</code></li>
<li class="block"><code>filter_type</code> ist <code>blacklist</code></li>
<li class="block">Und mit <code>redis_cache_ttl</code> etwas niedriger als ein Tag: 82800 Sekunden</li>
</ul>
<p>Beide Feeds werden einmal täglich abgeholt, dieser Vorgang wird mittels systemd timern gestartet. Für diesen Zweck nützen wir den <a href="https://intelmq.readthedocs.io/en/latest/user/configuration-management.html#scheduled-run-mode"><em>scheduled</em> run mode</a> und den <a href="https://github.com/certtools/intelmq/tree/master/contrib/systemd">systemd service generator</a>.</p>
<p>Zusammengefasst ergibt sich die Reihenfolge der eingesetzten Bots wie folgt:</p>
<ul>
<li>Abuse.ch URLhaus Country Feed Collector und Abuse.ch URLhaus TLD Feed Collector</li>
<li>Abuse.ch URLhaus Parser</li>
<li>Modify Expert</li>
<li>Sieve Expert</li>
<li>Deduplicator Expert</li>
<li>Weitere Verarbeitungsschritte</li>
</ul>
<hr />
<p class="block">This blog post is part of a series of blog posts related to our <a href="https://ec.europa.eu/inea/en/connecting-europe-facility/cef-telecom/2018-at-ia-0111">CEF Telecom 2018-AT-IA-0111</a> project, which also supports our participation in the CSIRTs Network.</p>
<p class="block"><img src="https://cert.at/media/files/news/blog/202002051545/en_cef-1024x146.png" alt="Co-financed by the European Union Connecting Europe Facility" width="1024" height="146" /></p>CERT.at2021-01-20T11:05:00ZOh ... Ransomware hat auch meine Backups verschlüsselt ... Was nun?CERT.at2020-10-30T12:33:38Z2020-10-30T09:30:00Z<p class="block">Das Thema Ransomware verfolgt Unternehmen weltweit nun schon ein bis zwei Jahrzehnte [1]. Es ist auch kein Trend zu erkennen, dass sich das bald ändern sollte. Es muss leider vom Gegenteil ausgegangen werden. Die Anzahl an Vorfällen ist besonders in den letzten Jahren gestiegen [2]. Angreifer setzten inzwischen nicht nur auf Verschlüsselung, sondern drohen mit der Veröffentlichung von Unternehmensdaten, welche vor dem Unbrauchbarmachen exfiltriert wurden, um die Zahlungswilligkeit der Opfer zu erhöhen. Es gibt auch Varianten die den Druck auf Unternehmen mittels Denial-of-Service Angriffen weiter verstärken [3].<br />Neben der von uns bereits 2016 veröffentlichten Information [4], die trotz ihres Alters immer noch aktuell ist, und den Hinweisen auf neue Methoden [5] beziehungsweise potentielle Abhilfen [6], nun zu einem anderen Aspekt der ebenso als eine Möglichkeit zur Wiederherstellung verschlüsselter Daten nach einem Ransomware-Vorfall dienen kann ...</p>
<h2 class="block">Backup-Snapshots auf Dateisystemebene</h2>
<p class="block">Moderne Network-Attached-Storage (NAS) Systeme, die auch gerne von kleinen und mittleren Unternehmen für die Sicherung von Daten genutzt werden, benutzen häufig klassisch LINUX-basierende Dateisysteme (EXT4, ZFS, BTRFS) welche direkt oder über systeminterne Lösungen Snapshots, also Momentaufnahmen des aktuellen Zustands der gespeicherten Daten, ermöglichen. Dies kann über die Verwaltungstools der jeweiligen NAS-Lösung konfiguriert und automatisiert werden. Da diese Schnappschüsse nur Änderungen des IST-Zustands aufzeichnen, ist der notwendige höhere Speicherbedarf im Normalfall gering, so dass zum Einsatz dieser Momentaufnahmen nicht unbedingt eine Speichererweiterung notwendig ist.<br />Aktuelle Ransomware fungiert fast ausschließlich auf der Windows Dateisystemebene und verschlüsselt daher die meist über Server Message Block (SMB) für das Backup freigegebenen Bereiche auf der NAS. Dies betrifft aber nicht das darunterliegenden native LINUX Dateisystem.</p>
<h2 class="block">Fazit</h2>
<p class="block">Wurde man Opfer eines Ransomwareangriffs und hatte Snapshots auf LINUX Dateisystemebene auf der NAS aktiviert, besteht nun die Möglichkeit zumindest einen Teil der Daten mittels Rückspielen der Momentaufnahme wiederherzustellen.</p>
<p class="block"><strong>Snapshots können echte OFFLINE-Backups nicht ersetzen und sind diesen nicht vorzuziehen, aber können im Notfall Abhilfe schaffen.</strong></p>
<p class="block"> </p>
<p class="block">[1] <a href="https://de.wikipedia.org/wiki/Ransomware#Historie">https://de.wikipedia.org/wiki/Ransomware#Historie</a><br />[2] <a href="https://www.enisa.europa.eu/publications/ransomware">https://www.enisa.europa.eu/publications/ransomware</a><br />[3] <a href="https://www.bleepingcomputer.com/news/security/ransomware-gangs-add-ddos-attacks-to-their-extortion-arsenal/">https://www.bleepingcomputer.com/news/security/ransomware-gangs-add-ddos-attacks-to-their-extortion-arsenal/</a><br />[4] <a href="https://cert.at/de/spezielles/2016/4/spezielles-20160325">https://cert.at/de/spezielles/2016/4/spezielles-20160325</a><br />[5] <a href="https://cert.at/de/aktuelles/2020/10/aktuelles-2020-10-22-ransomware">https://cert.at/de/aktuelles/2020/10/aktuelles-2020-10-22-ransomware</a><br />[6] <a href="https://cert.at/de/aktuelles/2020/10/raccine-eine-simple-methode-um-den-schutz-vor-ransomware-zu-erhohen">https://cert.at/de/aktuelles/2020/10/raccine-eine-simple-methode-um-den-schutz-vor-ransomware-zu-erhohen</a></p>CERT.at2020-10-30T09:30:00ZWeiterentwicklung des „Constituency-Portals“: Next GenerationCERT.at2020-10-29T20:36:15Z2020-10-27T11:13:00Z<p class="block"><em>This blogpost is also available in <a href="https://cert.at/en/news/blog/development-of-the-constituency-portal-20">English</a>.</em></p>
<p class="block">Die Intevation GmbH entwickelt die nächste Version des "Consituency-Portal", unser Tool zur Verwaltung von Kontaktadressen, .</p>
<p class="block">Die neue Version wird die bestehende Software ablösen, welche eine Weiterentwicklung des „<a href="https://github.com/certat/do-portal">do-portals</a>“ (entwickelt von CERT-EU) ist. Seit 2017 passten wir diese im Rahmen von <a href="https://cert.at/de/ueber-uns/projekte/abgeschlossen#CEF-2016-AT-IA-0089">CEF 2016-AT-IA-0089</a> an unsere Bedürfnisse an.</p>
<p class="block">Über die Jahre sind unsere Anforderungen erheblich gewachsen und die Softwarearchitektur war den Mehranforderungen nicht gewachsen, auch die Wartung wurde zunehmend schwieriger. Daher haben wir uns im im Frühjahr diesen Jahres für einen Neustart entschieden: Das Softwaredesign wird vollständig überarbeitet und auf Basis von <a href="https://laravel.com/">Laravel</a> und PHP neu implementiert. Über das Constituency-Portal werden wir auch die täglichen CERT-Aussendungen an Netzbetreiber mit <a href="https://github.com/certtools/intelmq/">IntelMQ</a> durch eine gezielte Zuordnung von Netzwerken und Domains zu Organisationen besser adressieren können. Geplant ist, dass die darin bereits vorhandenen Kontaktdaten in Zukunft von der Constituency selbst verwaltet werden können. Zu diesem Zweck werden NetzwerkbetreiberInnen die Möglichkeit haben, Accounts anzulegen. Die Authentifizierung soll über Keycloak erfolgen, mit dessen Hilfe auch in Zukunft entwickelte Dienste von <a href="https://www.energy-cert.at/de/">AEC</a>/CERT.at und <a href="https://www.govcert.gv.at/">GovCERT</a> integriert werden können.</p>
<p class="block">Die Entwicklung der Software erfolgt durch die <a href="https://intevation.de/">Intevation GmbH</a> aus Osnabrück als freie Software bis Sommer 2021 und ist zu großen Teilen aus <a href="https://cert.at/de/ueber-uns/projekte/aktuell#3-4-1-3">CEF 2018-AT-IA-0111</a> finanziert. Intevation hat im Rahmen anderer Projekte bereits IntelMQ maßgeblich weiterentwickelt. Die offene Entwicklungsweise unterstreicht unser Engagement für Freie Software und die internationale CERT-Gemeinschaft und das Werkzeug wird damit auch anderen CERTs/CSIRTs zur Verfügung stehen. Das Code-Repository ist auf <a href="https://gitlab.com/intevation/tuency/tuency">gitlab</a> zu finden.</p>
<hr />
<p class="block">This blog post is part of a series of blog posts related to our <a href="https://ec.europa.eu/inea/en/connecting-europe-facility/cef-telecom/2018-at-ia-0111">CEF Telecom 2018-AT-IA-0111</a> project, which also supports our participation in the CSIRTs Network.</p>
<p class="block"><img src="https://cert.at/media/files/news/blog/202002051545/en_cef-1024x146.png" alt="Co-financed by the European Union Connecting Europe Facility" width="1024" height="146" /></p>CERT.at2020-10-27T11:13:00ZIP Spoofing inbound verhindernCERT.at2020-10-21T14:23:44Z2020-10-21T14:22:00Z<p class="block">Die <a title="Brigham Young University" href="https://imaal.byu.edu/" target="_blank">Brigham Young University</a> schickt gerade Empfehlungsschreiben an Internet Provider aus, in denen darauf hingewiesen wird, dass es bei<br />diesen möglich ist, eingehende IP Pakete mit Source-Adressen aus dem Netz des Internet Providers zu empfangen.</p>
<p class="block">Das mag jetzt auf den ersten Blick nicht wie ein großes Problem aussehen - schließlich können Antwort-Pakete nur ins eigene Netz gesendet werden, und werden dort wohl einfach verworfen.</p>
<p class="block">In manchen Umgebungen ist es aber möglich, durch einzelne Pakete eine <em>neue</em> Verbindung anderswohin aufbauen zu lassen<br />- die ForscherInnen nehmen hier als Beispiel DNS:</p>
<p class="block">Nehmen wir an, der betroffene ISP nutzt 192.0.2.0/24 als IPv4-Adressen. Er bekommt nun ein Paket mit folgender DNS-Anfrage an seinen Resolver:</p>
<p class="block">Quelle: 192.0.2.253<br />Ziel: 192.0.2.1<br />Frage: IP-Adresse von Ziel.example?</p>
<p class="block">Der Resolver ist für die KundInnen da, die natürlich IP-Adressen aus dem Bereich des ISPs verwenden. Der Resolver sieht eine passende Adresse<br />als Anfrage-Quelle (192.0.2.253) und wird versuchen die Frage zu beantworten.<br />Dazu sieht er nun nach, welcher Nameserver für Ziel.example zuständig sind - nehmen wir hier an, das wäre 198.51.100.1 - und schickt nun seinerseits eine neue Frage dorthin.:</p>
<p class="block">Quelle: 192.0.2.1<br />Ziel: 198.51.100.1<br />Frage: IP-Adresse von Ziel.example?</p>
<p class="block">Auch das wird in einzelnen Fällen wohl kein großes Problem darstellen. Werden allerdings große Mengen solcher gefälschten Anfragen geschickt, kann das zu einer Überlastung des eigentlichen Ziels (im Beispiel 198.51.100.1) führen. Es ist ebenso denkbar, dass die Details der DNS-Frage und die gefälschte Quell-Adresse bei jeder Anfrage verschieden sind, und so bestehende Sicherungsmaßnahmen wie Rate Limits fehlschlagen.<br />Genauso ist es vorstellbar, dass AngreiferInnen gezielt Anfragen stellen, die große Antwortpakete auslösen, um damit ihr Ziel zu überlasten. Im Beispiel könnten das 192.0.2.1 oder das ihn umgebende Netzwerk sein.</p>
<p class="block">Kurz gesagt: ISPs sollten nicht nur ihre eigenen KundInnen daran hindern, Pakete mit gefälschten Absender-Adressen zu schicken (vgl. <a title="BCP38" href="https://tools.ietf.org/html/bcp38" target="_blank">BCP38</a>),<br />sondern auch an den Übergabepunkten zu ihren Upstreams/Peers dafür sorgen, dass keine Pakete mit Source-Adressen aus dem eigenen Netz<br />herein können.<br />Das ist technisch oft eine gewisse Herausforderung: einfache Filterlisten (ACLs) werden aufgrund der Ressourcen-Anforderungen meist<br />ausscheiden. Reverse-Path-Filter (RPF/uRPF) sind aber in den meisten Routern implementiert und deutlich "sparsamer" zu betreiben.<br />Auch manche Netzwerk-Topologien, zB in Umgebungen mit Multi-Homing oder Anycast-Setups, können hier ein gewisses Kopfzerbrechen auslösen.<br /><a title="RFC8704" href="https://tools.ietf.org/html/rfc8704" target="_blank">RFC8704</a> behandelt das Thema ausführlich, und in den meisten Fällen sollte sich eine praktikable Lösung finden lassen.</p>CERT.at2020-10-21T14:22:00ZRückblick auf das zweite Drittel 2020CERT.at2020-09-21T12:56:02Z2020-09-21T12:55:00Z<ul>
<li><a href="#mai-2020">Mai</a></li>
<li><a href="#juni-2020">Juni</a></li>
<li><a href="#juli-2020">Juli</a></li>
<li><a href="#august-2020">August</a></li>
</ul>
<h2 id="mai-2020">Mai</h2>
<p>Anders als das erste Jahresdrittel, begann das zweite wesentlich weniger dramatisch, was IT-Sicherheit angeht.</p>
<h3 id="vorfaelle-aussendungen-mai-2020">Vorfälle und Aussendungen</h3>
<p>Neben Citrix, dem auch im 2. Jahresdrittel unsere erste anlassbezogene Aussendung zu verdanken war, kam auch eine andere alte Schwachstelle zu neuem “Ruhm".</p>
<h4 id="citrix-sharefile-storagezones-controller">Citrix ShareFile StorageZones Controller</h4>
<p>Am 5. Mai <a href="https://support.citrix.com/article/CTX269106">gab Citrix bekannt</a>, dass mehrere Schwachstellen (<a href="https://nvd.nist.gov/vuln/detail/CVE-2020-7473">CVE-2020-7473</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-8982">CVE-2020-8982</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-8983">CVE-2020-8983</a>) in der Software des ShareFile StorageZones (alternativ auch “storage zones") Controller dafür sorg(t)en, dass AngreiferInnen Zugriff auf die dort gespeicherten Daten erhalten können – ganz ohne Authentifizierung.</p>
<p>Daran war vor allem unangenehm, dass ein einfaches Update nicht ausreichte, um sich zu schützen, da das Problem in den von verwundbaren Geräten erstellen Storage Zones selbst lag, d.h. auch aktualisierte Server, die alte Storage Zones verwendeten, waren weiterhin anfällig.</p>
<p>Wir identifizierten mithilfe von <a href="https://www.shodan.io/">shodan.io</a> potentiell für diese Lücken anfällige Geräte in Österreich und kontaktierten deren BetreiberInnen.</p>
<h4 id="qnap-nas">QNAP NAS</h4>
<p>In der zweiten Maihälfte wurde ein Exploit zu einer Schwachstelle in diversen QNAP NAS Geräten veröffentlicht, die es ermöglichte, sämtliche Dateien auf dem Gerät zu lesen und zu schreiben sowie beliebigen Code auszuführen; und all das ganz ohne lästige Authentifizierung. Das <a href="https://www.qnap.com/en/security-advisory/nas-201911-25">Update von QNAP</a> stand zwar bereits seit November 2019 bereit, war allerdings vielfach nicht eingespielt worden, sodass <a href="https://medium.com/bugbountywriteup/qnap-pre-auth-root-rce-affecting-450k-devices-on-the-internet-d55488d28a05">einer Schätzung zufolge</a> im Mai 2020 immer noch bei etwa 312.000 Geräte, die aus dem öffentlichen Internet erreichbar waren, die Lücke nicht behoben war.</p>
<p>Wiederum suchten wir mittels <a href="https://www.shodan.io/">shodan.io</a> nach potentiell betroffenen Geräten in Österreich und verschickten E-Mails mit der Bitte um möglichst zeitnahe Updates.</p>
<h3 id="projekte-konferenzen-mai-2020">Projekte und Konferenzen</h3>
<p>Im Mai fand das erste virtuelle TF-CSIRT Meeting statt, an dem Sebastian Wagner und Aaron Kaplan teilnahmen. Eine Zusammenfassung findet sich unter <a class="uri" href="https://connect.geant.org/2020/06/01/virtual-tf-csirt">https://connect.geant.org/2020/06/01/virtual-tf-csirt</a>.</p>
<p>Außerdem nahm im Mai das Projekt MeliCERTes an Fahrt auf. Dieses hat zum Ziel, eine gemeinsame "Toolbox", die wo immer möglich aus Open Source Projekten besteht, für nationale CERTs/CSIRTs in der EU zu schaffen. Dadurch soll nicht nur neuen CERTs/CSIRTs der Einstieg erleichtert werden, sondern auch die Entwicklung der Open Source Lösungen gefördert werden. Details zum Projekt finden sich auf <a href="https://cert.at/de/ueber-uns/projekte/#melicertes-smart-2018-2014">https://cert.at/de/ueber-uns/projekte/#melicertes-smart-2018-2014</a>.</p>
<h2 id="juni-2020">Juni</h2>
<p>Auch der Juni wartete mit einigen Schwachstellen auf und brachte wieder erste Erinnerungen an die seit Februar 2020 verdächtig ruhige Emotet-Schadsoftware.</p>
<h3 id="vorfaelle-aussendungen-juni-2020">Vorfälle und Aussendungen</h3>
<h4 id="vmware-vcenter-server">VMWare vCenter Server</h4>
<p>Im Juni machte eine Aussendung zu VMWares vCenter Server den Anfang. Dieser hatte bereits im April mit <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-3952">CVE-2020-3952</a> eine glatte 10.0 auf der CVSS 3.0 Skala hingelegt, aber auch direkt ein Update erhalten. Die Schwachstelle ermöglicht(e) es AngreiferInnen, sensible Daten, wie etwa das Passwort eines Administrations-Accounts über das Netzwerk und ohne Authentifizierung auszulesen.</p>
<p>Während bereits im April ein <a href="https://github.com/guardicore/vmware_vcenter_cve_2020_3952">Proof of Concept zum Ausnützen der Lücke</a> veröffentlicht worden war, erschien am 1.6. ein <a href="https://www.exploit-db.com/exploits/48535">“richtiger" Exploit</a> dazu.</p>
<p>Wir nahmen das zum Anlass, um nach öffentlich erreichbaren vCenter Server Instanzen in Österreich zu scannen und informierten Betroffene.</p>
<h4 id="exim">Exim</h4>
<p>Auch Exim hatte schon im September 2019 mehrere kritische Schwachstellen (<a href="https://nvd.nist.gov/vuln/detail/CVE-2019-10149">CVE-2019-10149</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2019-15846">CVE-2019-15846</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2019-16928">CVE-2019-16928</a>) geschlossen, die eine Remote Code Execution mit <code>root</code>-Rechten ermöglichten.</p>
<p>Es stellte sich aber heraus, dass die notwendigen Updates vielfach nicht eingespielt worden waren und weltweit etwa 1 Million verwundbare Exim-Instanzen via <a href="https://www.shodan.io/">shodan.io</a> identifiziert werden konnten (vgl. den <a href="https://heise.de/-4772712">Artikel auf Heise.de</a>).</p>
<p>Wir filterten die potentiell anfälligen Exim-Installationen in Österreich aus den Ergebnissen heraus und kontaktierten die BetreiberInnen.</p>
<h4 id="apache-tomcat-ghostcat">Apache Tomcat: Ghostcat</h4>
<p>Bereits im Februar hatten wir von einem befreundeten CERT Informationen zu von der <a href="https://www.tenable.com/blog/cve-2020-1938-ghostcat-apache-tomcat-ajp-file-readinclusion-vulnerability-cnvd-2020-10487">Ghostcat getauften Schwachstelle</a> betroffenen Geräten in Österreich erhalten und ausgeschickt.</p>
<p>Im Juni erhielten wir erneut eine Liste von Instanzen, die nach wie vor nicht auf dem aktuellen Stand waren und wiederholten den Vorgang.</p>
<h4 id="emotet-returns-not-yet">Emotet Returns (not yet)</h4>
<p>Außerdem erhielten wir von einem befreundeten CERT eine Liste von mit Emotet infizierten Geräten in Österreich. Die Informationen waren zwar schon etwas älter und um die Schadsoftware war es zu diesem Zeitpunkt einige Monate sehr ruhig geworden, aber wir kontaktierten natürlich trotzdem die BetreiberInnen und baten um eine rasche Bereinigung im eigenen Interesse – vor allem, wenn es noch zu keinen weiteren Schritten der Kriminellen gekommen war.</p>
<h3 id="projekte-konferenzen-juni-2020">Projekte und Konferenzen</h3>
<h4 id="projekte">Projekte</h4>
<p>Mitte Juni nahmen wir einen Feed der Firma Bitsight in unsere Aussendungen auf, der Informationen über mit Malware oder Adware befallene Geräte enthält. Nähere Informationen finden sich im <a href="https://cert.at/de/blog/2020/6/bitsight-cyberfeed-als-neue-datenquelle-fur-unsere-aussendungen-aufgenommen">damals veröffentlichten Blogpost</a>.</p>
<p>Eine Woche später erschienen mit IntelMQ 2.1.3 und 2.2.0 ein Maintenance- und ein Feature-Release der von uns betreuten Open Source Software. Wiederum gibt es <a href="https://cert.at/en/blog/2020/6/intelmq-releases-213-and-220">auf unserem Blog</a> eine genauere Übersicht dazu, was die neuen Versionen jeweils umfassten.</p>
<p>Außerdem veröffentlichten wir Ende Juni die Tools, mit denen wir Certificate Transparency Logs bearbeiten <a href="https://github.com/certat/certspotter-processing">auf Github</a>. Dabei monitoren das Austrian Energy CERT (AEC) und GovCERT Austria, welche neuen TLS-Zertifikate für Webseiten der jeweiligen Constituency ausgestellt werden, und informieren die betroffenen Sicherheitsabteilungen.</p>
<p>Diese können dann sofort überprüfen, ob es sich um ein legitimes Zertifikat handelt, oder aber ein potentieller Angriff vorliegt.</p>
<h4 id="konferenzen">Konferenzen</h4>
<p>Nach anfänglichen Absagen von Konferenzen aufgrund der Reise- und Versammlungsbeschränkungen, wurde mit der Zeit und nach Möglichkeit auf Online-Formate umgestellt. Im Juni hatten sich langsam alle daran gewöhnt und auch CERT.at nahm an einigen Remote-Veranstaltungen teil.</p>
<p>Sebastian Wagner und Otmar Lendl nahmen am <a href="https://www.enisa.europa.eu/events/11th-csirts-network-meeting">11. CSIRTs Network Meeting</a> teil, das von 2020-06-03 – 2020-06-04 stattfand.</p>
<p>Am 22. Juni gab es ein virtuelles EGC (European GovCERT Group) Meeting, bei dem Otmar Lendl dabei war.</p>
<p>Während die FIRST Conference 2020 wegen COVID-19 auf November verschoben wurde, wurde der geplante <a title="https://www.first.org/events/web/ctf-jun2020/" href="https://www.first.org/events/web/ctf-jun2020/">FIRST-CTF</a> dennoch abgehalten; diesmal eben online. Von CERT.at nahmen Dimitri Robl und Sebastian Wagner teil und erreichten gemeinsam Platz 42 von etwa 200 Teams.</p>
<h2 id="juli-2020">Juli</h2>
<p>Nachdem wir also bereits im Vormonat wieder erste Berührungspunkte haben durften, kehrte Emotet im Juli in voller Stärke zurück und spammte was das Zeug hielt.</p>
<h3 id="vorfaelle-aussendungen-juli-2020">Vorfälle und Aussendungen</h3>
<h4 id="citrix-shitrix">Citrix-Shitrix</h4>
<p>Auch wenn die “Shitrix" getaufte Schwachstelle zu Beginn des Jahres viel Aufmerksamkeit bekommen hatte, war sie offensichtlich nicht allen bekannt geworden: Wir erhielten Anfang Juli eine Liste von nach wie vor potentiell verwundbaren Geräten in Österreich und schickten die Informationen an die Betroffenen weiter.</p>
<h4 id="palo-alto-pan-os">Palo Alto PAN-OS</h4>
<p>Ende Juni wurde in Palo Altos PAN-OS mit <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-2021">CVE-2020-2021</a> eine kritische Schwachstelle mit einem CVSSv3 Score von 10.0 behoben.</p>
<p>Wir bekamen Anfang Juli eine Liste von in Österreich betroffenen Geräten und schickten eine Warnung an die BetreiberInnen aus.</p>
<h4 id="emotet-returns-for-real">Emotet Returns (for real)</h4>
<p>Und dann kam Emotet zurück – mit neuem Code, neuen Tricks und neuen Pannen.</p>
<p>Die Kriminellen hinter der Schadsoftware dürften die Monate seit Februar für eine ausgiebige Überarbeitung des Codes und dem Hinzufügen neuer Optionen genutzt haben.</p>
<p>Eine neue Fähigkeit der Malware war nun, dass sie nicht nur auf gestohlene E-Mails antwortete, um glaubwürdiger zu erscheinen, sondern auch gestohlene E-Mail Anhänge zweckentfremdete, wie unter anderem <a href="https://www.bleepingcomputer.com/news/security/emotet-malware-now-steals-your-email-attachments-to-attack-contacts/">Bleeping Computer berichtete</a>. Dabei werden legitime Anhänge zusätzlich zu den bösartigen an E-Mails angehängt.</p>
<p>Aber wie auch bei anderer Software, lief (in diesem Fall erfreulicherweise) nicht alles glatt beim neuen "Release". Eine unbekannte Person fand relativ schnell eine Lücke in der Infrastruktur von Emotet und ersetzte die Malware durch ungefährliche GIF-Dateien wie z.B. <a href="https://www.golem.de/news/malware-emotet-server-gehackt-2007-149903.html">golem.de berichtete</a>.</p>
<h3 id="projekte-konferenzen-juli-2020">Projekte und Konferenzen</h3>
<h4 id="projekte-1">Projekte</h4>
<p>Im Juli stellten wir das Projekt <code>tag2domain</code> in <a href="https://cert.at/en/blog/2020/7/tag2domain">einem Blogpost</a> vor. Dabei handelt es sich um einen Versuch, eine Taxonomie zu entwickeln, nach der DNS-Domains basierend auf Tags klassifiziert und darauf basierend Statistiken erstellt werden können – beispielsweise welche Domains in welchen Wirtschaftszweig fallen.</p>
<p>Diese Taxonomie muss einerseits flexibel sein, um die Einbindung neuer Kategorien zu ermöglichen, darf aber andererseits nicht in Massen an Kategorien untergehen, damit sinnvolle statistische Abfragen möglich bleiben. Angelehnt wurde sie an jene von <a href="https://www.misp-project.org/">MISP</a>.</p>
<p>Ein anderes Projekt, das im Juli große Fortschritte zu verzeichnen hatte, war SIRF, das Security Incident Response Framework.</p>
<p>Seit Juli wird CERT.at außerdem von Clemens Moritz aus der <a href="https://www.nic.at/en/team/research-and-development">R&D Abteilung der nic.at</a> bei der Umsetzung eines Webcrawlers für das Project <a href="https://cert.at/de/ueber-uns/projekte/#3-4-1-3">“Enhancing Cybersecurity in Austria" (2018-AT-IA-0111)</a> unterstützt.</p>
<h2 id="august-2020">August</h2>
<p>Auch der August war gefüllt mit Emotets Umtrieben.</p>
<h3 id="vorfaelle-aussendungen-august-2020">Vorfälle und Aussendungen</h3>
<h4 id="emotet-soweit-das-auge-reicht">Emotet soweit das Auge reicht</h4>
<p>Im August lief Emotet auf Hochtouren. Anfang des Monats wurde öffentlich bekannt, dass eine bis dahin in IT-Sicherheitskreisen kursierende Lücke namens "EmoCrash", die die Schadsoftware zum Absturz brachte, mit einem neuen Update des Schädlings nicht mehr funktionierte. Bis zu diesem Zeitpunkt wurde diese "Impfung" unter der Hand weitergegeben, um nicht die Aufmerksamkeit der Kriminellen zu erregen und dennoch möglichst viele Menschen vor den Angriffen zu schützen. Am 6.8. war damit leider Schluss, vgl. <a href="https://www.binarydefense.com/emocrash-exploiting-a-vulnerability-in-emotet-malware-for-defense/">den Blogpost von BinaryDefense</a>.</p>
<p>CERT.at machte im Verlauf des Augusts drei Emotet-bezogene Aussendungen, die sich an BesitzerInnen infizierter Geräte bzw. spammender E-Mail-Accounts wandten.</p>
<h4 id="ein-neuer-feed-accessible-ubiquiti-service-discovery">Ein neuer Feed: Accessible Ubiquiti Service Discovery</h4>
<p>Mit dem <a href="https://www.shadowserver.org/what-we-do/network-reporting/open-ubiquiti-report/">Open Ubiquiti Report</a><a id="fnref1" class="footnote-ref" href="#fn1"><sup>1</sup></a><a href="https://www.shadowserver.org/what-we-do/network-reporting/open-ubiquiti-report/"> von Shadowserver</a> kam im August auch ein neuer Feed zu unsere Aussendungen hinzu. Dieser enthält erstmals auch Einträge, die unter die Taxonomie “<code>intrusions</code>" zu zählen sind, da bei manchen der Geräte klar ersichtlich ist, dass sie bereits gehackt wurden.</p>
<p>Eine genauere Beschreibung des Feeds findet sich <a href="https://cert.at/de/services/daten-feeds/shadowserver/#accessible-ubiquiti-discovery">auf unserer Webseite</a>.</p>
<h3 id="projekte-konferenzen-august-2020">Projekte und Konferenzen</h3>
<p>Im August wurde endgültig beschlossen, eine neue Version des Constituency-Portals zu entwickeln, weil sich im Verlauf des Projekts herausstellte, dass die zugrundeliegende Struktur den Anforderungen nicht entspricht. Die <a title="https://github.com/certat/do-portal" href="https://github.com/certat/do-portal">aktuelle Version</a> befindet sich im Maintenance Mode, d.h. sie wird nicht mehr weiterentwickelt.</p>
<p>Außerdem gaben wir Ende August den zweiten Interimsreport zu <a href="https://cert.at/de/ueber-uns/projekte/#3-4-1-3">“Enhancing Cybersecurity in Austria" (2018-AT-IA-0111)</a> ab.</p>
<section class="footnotes"><hr />
<ol>
<li id="fn1">
<p>Nein, die Inkohärenz in der Benennung ist uns nicht entgangen – die kommt direkt von der Quelle selbst, da die Webseite ihn als "Open Ubiquiti Report" bezeichnet, die E-Mail Reports aber von "Accessible Ubiquiti Service Discovery" schreiben.<a class="footnote-back" href="#fnref1">↩</a></p>
</li>
</ol>
</section>CERT.at2020-09-21T12:55:00Z"Accessible Ubiquiti Service Discovery": Erster Datenfeed in der Taxonomie "Intrusions"CERT.at2020-09-01T11:17:55Z2020-09-01T11:15:00Z<p class="block">Ubiquiti Geräte benutzen ein Discovery Protokoll, um sich gegenseitig automatisch zu erkennen. Während das innerhalb des eigenen Netzwerks nützlich sein kann, machen fehlerhaft konfigurierte Geräte eine Vielzahl an Daten über sich öffentlich abrufbar. Als wäre dieses Problem nicht genug, gab es in älteren Firmware-Versionen eine Schwachstelle, die eine automatisierte Übernahme der betroffenen Systeme ermöglicht(e).</p>
<p class="block">Basierend auf dem <a title="https://www.shadowserver.org/what-we-do/network-reporting/open-ubiquiti-report/" href="https://www.shadowserver.org/what-we-do/network-reporting/open-ubiquiti-report/">"Open Ubiquiti Report" von Shadowserver</a> filtern wir jene Geräte heraus, die in der Spalte <code>radioname</code> das Wort "HACKED" enthalten. Diese Herangehensweise findet natürlich nicht alle, die infiziert sind, hat aber dafür eine hohe Trefferquote, da der Begriff in einigen bekannten, vermutlich gut-gemeinten, "Angriffen" zum Einsatz kam, um BetreiberInnen zu warnen, dass ihre Geräte infiziert sind (vgl. dazu z.B. einen <a title="https://www.zdnet.com/article/over-485000-ubiquiti-devices-vulnerable-to-new-attack/" href="https://www.zdnet.com/article/over-485000-ubiquiti-devices-vulnerable-to-new-attack/">Artikel von ZDNet</a>). Die daraus resultierenden Aussendungen haben den Betreff "Network intrusion incidents", der bisher nicht von uns verwendet wurde.</p>
<p class="block">Eine genauere Beschreibung der Probleme mit der Ubiquiti Service Discovery und mögliche Gegenmaßnahmen finden Sie unter <a href="https://cert.at/de/services/daten-feeds/shadowserver/#accessible-ubiquiti-discovery">https://cert.at/de/services/daten-feeds/shadowserver/#accessible-ubiquiti-discovery</a>.</p>
<p class="block">Sollten Sie eine solche Aussendung von uns erhalten, würden wir uns sehr über Feedback an <a href="mailto:team@cert.at">team@cert.at</a> freuen, ob die Information nützlich für Sie war bzw. was notwendig ist, damit sie das wird.</p>CERT.at2020-09-01T11:15:00ZUpgrade unseres Ticketsystems 2020-08-07CERT.at2020-08-07T12:21:48Z2020-08-07T10:50:00Z<p class="block">Viele unserer Prozesse laufen über ein Ticketsystem, in unserem Fall ist das <a href="https://bestpractical.com/rtir">RTIR</a>.</p>
<p class="block">Es ist jetzt Zeit geworden, hier eine radikalere Umstellung zu machen:</p>
<ul>
<li class="block">Neue Version (Und natürlich wurde prompt während der Testphase eine radikal neue herausgegeben. Seufz.)</li>
<li class="block">Komplett neue Installation incl. Datenbank (wir wollen einiges an alten Zöpfen abschneiden, da ist ein in-place upgrade nicht hilfreich)</li>
<li class="block">Neues Setup zu Verschlüsselung / Signierung von Emails (damit sollten wir dann PGP und S/MIME können)</li>
</ul>
<p class="block">Wir haben zwar die Kernprozesse getestet, aber es mag da oder dort initial nicht alles so rund laufen, wie wir es die letzten jahre gewohnt waren.</p>
<p class="block">Daher die doppelte Bitte: a) wir bitte um Verständnis, wenn was noch nicht perfekt ist und b) bitte nicht nur im Stillen ärgern, sondern auch Probleme an <a href="mailto:team@cert.at">team@cert.at</a> melden, damit wir alles geradeziehen können.</p>CERT.at2020-08-07T10:50:00ZBitsight Cyberfeed als neue Datenquelle für unsere Aussendungen aufgenommenCERT.at2020-06-15T12:52:07Z2020-06-15T12:10:00Z<p class="block">Seit Freitag, 12. Juni 2020 schicken wir die Daten aus einem Feed der Firma Bitsight aus. Darin enthalten sind Informationen zu potentiell mit Malware oder Adware befallenen Geräten. Da uns die Definition von Adware zu schwammig ist, haben wir uns dazu entschieden, nur jene Fälle auszuschicken, bei denen der Feed von Malware ausgeht. Allerdings ist es automatisiert nicht immer leicht zu entscheiden, was Malware und was Adware ist; sollten Sie eine Nachricht über infizierte Systeme in Ihrem Netz erhalten, die in der Spalte <code>feed</code> den Wert <code>bitsight-cyberfeed</code> enhält (vgl. <a title="https://cert.at/de/services/daten-feeds/" href="https://cert.at/de/services/daten-feeds/">CERT.at Data feeds</a>) und feststellen, dass es sich dabei nicht um Malware handelt, bitten wir um Rückmeldung an <a href="mailto:team@cert.at">team@cert.at</a>. Auch anderes Feedback zu der neuen Datenquelle ist gerne gesehen.</p>
<p class="block">Das kommende 2.2.0 Release der Open-Source Software IntelMQ wird den Code, den wir zu Verarbeitung der Daten nutzen (insbesondere das Parsen des Feeds), beinhalten.</p>
<hr />
<p class="block">This blog post is part of a series of blog posts related to our <a href="https://ec.europa.eu/inea/en/connecting-europe-facility/cef-telecom/2018-at-ia-0111">CEF Telecom 2018-AT-IA-0111</a> project, which also supports our participation in the CSIRTs Network.</p>
<p class="block"><img src="https://cert.at/media/files/news/blog/202002051545/en_cef-1024x146.png" alt="Co-financed by the European Union Connecting Europe Facility" width="1024" height="146" /></p>CERT.at2020-06-15T12:10:00ZRückblick auf das erste Drittel 2020CERT.at2020-05-12T11:30:52Z2020-05-12T11:15:00Z<ul>
<li><a href="#jaenner-2020">Jänner: BMEIA, Shitrix, BlueGate – ein besinnlicher Jahresbeginn</a></li>
<li><a href="#februar-2020">Februar: Die (fast) letzten Augenblicke von TLS < 1.2</a></li>
<li><a href="#maerz-april-2020">März und April: COVID-19 oder "Im Cyber nix neues"</a></li>
</ul>
<h2 id="jaenner-2020">Jänner: BMEIA, Shitrix, BlueGate – ein besinnlicher Jahresbeginn</h2>
<p>Nachdem 2018 mit Spectre und Meltdown schon gezeigt hatte, wie der Start eines neuen Jahres in der IT-Sicherheitsbranche großes Chaos auslösen kann, war es Anfang 2019 erfreulich ruhig geblieben. 2020 positionierte sich weltweit wohl ungefähr zwischen den beiden, in Österreich gab es sich aber alle Mühe, an 2018 anzuschließen.</p>
<h3 id="vorfaelle-aussendungen-jaenner-2020">Vorfälle und Aussendungen</h3>
<p>Der Vorfall im BMEIA und die Schwachstelle in Citrix-Geräten waren zwar die größten Vorkommnisse, aber auch nicht die einzigen.</p>
<h4 id="bmeia-und-shitrix">BMEIA und Shitrix</h4>
<p>Der Jänner begann mit zwei Paukenschlägen: Das Außenministerium war zum Ziel einer mutmaßlich staatlichen Hacking-Gruppe geworden<a id="fnref1" class="footnote-ref" href="#fn1"><sup>1</sup></a> und aufgrund der engen Verbindung zwischen CERT.at und GovCERT Austria waren drei Personen aus unserem Team das gesamte Monat im externen Dauereinsatz. Aber auch den im Büro Verbliebenen wurde nicht langweilig: Bereits am 17. Dezember 2019 hatte Citrix in <a href="https://support.citrix.com/article/CTX267027">einem Advisory</a> bekanntgegeben, dass es eine kritische Lücke (<a href="https://nvd.nist.gov/vuln/detail/CVE-2019-19781">CVE-2019-19781</a>, Spitzname "Shitrix") in einigen ihrer Produkte gab und <a href="https://support.citrix.com/article/CTX267679">Workarounds zur Verfügung gestellt</a>. Diese wurden allerdings (vermutlich aufgrund der weltweit verbreiteten Feiertage zum Jahreswechsel) in vielen Fällen nicht zeitgerecht eingespielt, und richtige Updates wurden erst in der zweiten Jännerhälfte zu Verfügung gestellt.</p>
<p>Am 10. Jänner wurde der erste Exploit auf GitHub veröffentlicht, und spätestens da zeigte sich, wie einfach die Lücke auszunutzen war: Mit wenigen HTTP-Requests mit einem bestimmten Pfad konnten AngreiferInnen über das Netzwerk beliebige Befehle auf den Geräten ausführen ohne irgendwelche Zugangsdaten zu benötigen. Dementsprechend haben wir am selben Tag mit nach potentiell verwundbaren Systemen in Österreich gesucht und Betroffene informiert. Außerdem veröffentlichten wir in der Folgewoche einen <a href="https://cert.at/de/blog/2020/1/citrix-cve-2019-19781-aktiv-ausgenutzt">Blogpost</a> dazu. Waren es damals 344 potentiell verwundbare Systeme, finden sich aktuell weniger als 20 in Österreich.</p>
<p>Zusätzlich zu diesen beiden großen Vorkommnissen, gab es noch einige weitere:</p>
<h4 id="rdp-bluegate">RDP-Bluegate</h4>
<p>In Microsofts Patch Tuesday am 14. Jänner wurden Schwachstellen im RDP-Gateway (<a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0609">CVE-2020-0609</a>, <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0610">CVE-2020-0610</a>), die den Namen “BlueGate" erhielten, geschlossen und auch dafür waren bald Exploits auf GitHub verfügbar. Wir erhielten Informationen zu wahrscheinlich anfälligen Systemen von einem anderen CERT aus der EU und informierten auch hier die Betroffenen.</p>
<h4 id="sharepoint">SharePoint</h4>
<p>Bereits Anfang 2019 stellte Microsoft Updates für <a href="https://nvd.nist.gov/vuln/detail/CVE-2019-0604">CVE-2019-0604</a>, einer Remote Code Execution auf SharePoint Servern, zur Verfügung. Diese waren aber ein Jahr später immer noch nicht überall eingespielt und nachdem wir von externen ResearcherInnen eine Liste nach wie vor ungepatchter Instanzen in Österreich erhielten, kontaktierten wir die Betroffenen.</p>
<h4 id="trickbot-und-emotet">Trickbot und Emotet</h4>
<p>Ein befreundetes CERT schickte uns Daten zu Opfern mit Trickbot bzw. Emotet infizierten Systemen. Wir kontaktierten die Opfer mit dem dringlichen Hinweis, die befallenen Computer so schnell wie möglich zu bereinigen.</p>
<h3 id="projekte-konferenzen-jaenner-2020">Projekte und Konferenzen</h3>
<p>Wir veröffentlichten nicht nur Version 2.1.2 von IntelMQ (siehe den dazu verfassten <a href="https://cert.at/en/blog/2020/1/intelmq-version-212-released">Blogpost</a>), sondern auch ein <a href="https://github.com/certtools/intelmq-tutorial">Tutorial</a> zu dessen Nutzung.</p>
<p>Beim TF-CSIRT Treffen im Jänner wurde dieses auch gleich <a href="https://www.first.org/events/symposium/malaga2020/program#pIntelMQ-0">im Zuge eines Workshops</a> erprobt.</p>
<p>Außerdem bekamen wir Mitte des Monats Verstärkung für das Handlerteam.</p>
<h2 id="februar-2020">Februar: Die (fast) letzten Augenblicke von TLS < 1.2</h2>
<h3 id="vorfälle-und-aussendungen">Vorfälle und Aussendungen</h3>
<p>Im Februar war es insgesamt etwas ruhiger, aber dafür stand mit der für März angekündigten Entfernung von TLS 1.0 und 1.1 eine ebenfalls IT-Sicherheitsrelevante Veränderung in den Startlöchern.</p>
<h4 id="rip-tls-1.2-oder-doch-nicht">RIP TLS < 1.2 (oder doch nicht?)</h4>
<p>Die großen Browserherstellerfirmen Google, Mozilla, Microsoft und Apple hatten bereits 2018 angekündigt<a id="fnref2" class="footnote-ref" href="#fn2"><sup>2</sup></a>, dass sie im März 2020 die Unterstützung für TLS-Versionen unter 1.2 einstellen würden. Dementsprechend sind Webserver, die ausschließlich TLS 1.1 und darunter unterstützen ab dem Zeitpunkt dieser Umstellung von Chrom(ium|e), Firefox, Edge und Safari nicht mehr ohne weiteres erreichbar.</p>
<p>Wir nahmen das zum Anlass, um uns die Situation in Österreich anzusehen, indem wir alle .at-Domains auf die höchste von ihnen unterstützte TLS (bzw. in einigen wenigen Fällen SSL) Version testeten.</p>
<p>Anfang Februar fanden wir so etwa 4500 Systeme und informierten deren BetreiberInnen über den baldigen, potentiell unfreiwilligen Abschied aus dem WWW. Als wir den Scan am Ende desselben Monats wiederholten, hatte sich die Anzahl um knapp 1200 reduziert.</p>
<p>Aufgrund der COVID-19 Pandemie wurde die Deaktivierung von TLS 1.0 und 1.1 zwar bis auf weiteres verschoben,<a id="fnref3" class="footnote-ref" href="#fn3"><sup>3</sup></a> dennoch ist es ratsam auf TLS 1.3 umzusteigen, falls dies noch nicht geschehen ist.</p>
<h4 id="ghostcat-lfi-turned-rce">Ghostcat: LFI turned RCE</h4>
<p>Außerdem brachte uns der Februar noch <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-1938">CVE-2020-1938</a>, eigentlich eine Local File Inclusion Schwachstelle in Apache Tomcat, d.h. eine Lücke bei der es möglich ist, beliebige Dateien auf den Server zu laden. Allerdings konnte diese zumindest in einigen Fällen zu einer Unauthenticated Remote Code Execution "erweitert" werden, nämlich dann, wenn ausführbare Dateien hochgeladen wurden und von extern darauf zugegriffen werden konnte.</p>
<p>Eine genauere Darstellung findet sich in einem <a href="https://www.tenable.com/blog/cve-2020-1938-ghostcat-apache-tomcat-ajp-file-readinclusion-vulnerability-cnvd-2020-10487">Blogpost von Tenable</a>.</p>
<p>Auch in diesem Fall bekamen wir Informationen von einem befreundeten CERT über angreifbare Instanzen in Österreich und warnten die Betroffenen, da bereits ein Exploit auf GitHub verfügbar war.</p>
<h2 id="maerz-april-2020">März und April: COVID-19 oder "Im Cyber nix neues"</h2>
<p>März und April standen ganz im Zeichen der COVID-19 Pandemie und aufgrund der massenhaften Umstellung auf Homeoffice und den damit einhergehenden Installationen von VPNs, RDPs, etc. war durchaus anzunehmen, dass es im IT-Sicherheitsbereich einiges an Mehrarbeit geben würde.</p>
<p>Das hat sich jedoch (bisher) nicht bewahrheitet – natürlich gab es massenhaft Phishing-Mails und Fake-Shops, die auf den Corona-Zug aufsprangen, aber einen gröberen Anstieg an Vorfällen gab es nicht. Das ist keinesfalls nur in Österreich der Fall, sondern wurde von vielen anderen europäischen und internationalen CERTs mit denen wir in Kontakt sind, berichtet.</p>
<p>Obwohl wir im IT-Sicherheitsbereich also keine großen Neuigkeiten zu verbuchen hatten, ging die Ausbreitung des COVID-19 Virus auch an uns nicht ohne ungeplante Veränderungen vorüber: Die Reisebeschränkungen verhinderten nicht nur Fortbildungen und Konferenzbesuche, sondern vereitelten unter anderem auch die für Ende März sowie für April geplanten Hackathons, die im Rahmen des <a href="https://cert.at/de/ueber-uns/projekte/#3-4-1-3">2018-AT-IA-0111 Projekts</a> hätten stattfinden sollen.</p>
<h3 id="vorfaelle-aussendungen-maerz-april-2020">Vorfälle und Aussendungen</h3>
<p>Auch wenn COVID-19 nicht zu einem IT-Sicherheit-Alptraum wurde, gab es auch in diesen beiden Monaten Sicherheitslücken, denen wir nachgegangen sind:</p>
<h4 id="zoho-manageengine-desktop-central">Zoho ManageEngine Desktop Central</h4>
<p>In Desktop Central von ManageEngine, einem System mit dem Clients und Server remote und zentral gesteuert werden können, wurde mit <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-10189">CVE-2020-10189</a> eine unauthenticated Remote Code Execution bekannt für die es auch einen Proof of Concept Exploit gab.</p>
<p>Wir suchten über shodan.io nach potentiell verwundbaren Systemen in Österreich und informierten die Betroffenen.</p>
<h4 id="microsoft-exchange-cve-2020-0688">Microsoft Exchange: CVE-2020-0688</h4>
<p>Bereits im Februar hatte Microsoft mit <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-0688">CVE-2020-0688</a> eine kritische Lücke im Exchange Server behoben, die Remote Code Execution ermöglichte. Im Laufe von zwei Monaten wurden Exploits veröffentlicht und die Berichte über Angriffswellen häuften sich. Daher versuchten wir Anfang April, soviele ungepatchte Systeme wie möglich zu finden und kontaktieren deren BetreiberInnen mit der Bitte, die Updates möglichst bald einzuspielen.</p>
<p>Nähere Informationen dazu finden sich in unserem <a href="https://cert.at/de/blog/2020/4/cve-2020-0688-verwundbare-microsoft-exchange-server-in-osterreich">Blogpost</a> dazu. Ein erneuter Scan etwa ein Monat später lieferte quasi identische Zahlen zu den im soeben erwähnten Blogpost angeführten: 1043 ungepatchte Exchange Server insgesamt (im Vergleich zu 1096 im Monat davor) mit folgender Verteilung:</p>
<ul>
<li>
<p>Exchange Server 2013: 243 (vormals 245)</p>
</li>
<li>
<p>Exchange Server 2016: 712 (vormals 767)</p>
</li>
<li>
<p>Exchange Server 2019: 88 (vormals 84)</p>
</li>
</ul>
<p>Allerdings ist seither bekannt geworden, dass die Versionsstrings in den URLs, die das Script von CERT.LV für den Test verwendet, bei einem Update nicht aktualisiert werden und diese Ergebnisse daher leider nicht verlässlich sind.<a id="fnref4" class="footnote-ref" href="#fn4"><sup>4</sup></a></p>
<h4 id="sophos-xg-firewall">Sophos XG Firewall</h4>
<p>Die IT-Security Firma Sophos veröffentlichte Ende April <a href="https://community.sophos.com/kb/en-us/135412">ein Advisory</a> in dem sie auf eine SQL-Injection (<a href="https://nvd.nist.gov/vuln/detail/CVE-2020-12271">CVE-2020-12271</a>) in ihrer XG Firewall hinwiesen. Gleichzeitig erschien <a href="https://news.sophos.com/en-us/2020/04/26/asnarok/">ihre detaillierte Analyse</a> einer laufenden Kampagne, die diese Schwachstelle ausnutzte.</p>
<p>CERT.at nutzte shodan.io um potentiell anfällige Installationen der Sophos XG Firewall in Österreich zu identifizieren und informierte die Betroffenen.</p>
<h4 id="intelmq-manager">IntelMQ-Manager</h4>
<p>Wie <a href="#projekte-konferenzen-maerz-april-2020">im nächsten Abschnitt</a> näher beschrieben, wurde im April eine schwerwiegende Schwachstelle in einem von uns betreuten Open Source Projekt gefunden. Wir suchten via shodan.io nach potentiell angreifbaren Instanzen in Österreich und warnten die Betroffenen.</p>
<h3 id="projekte-konferenzen-maerz-april-2020">Projekte und Konferenzen</h3>
<p>Der April brachte uns auch unsere erste CVE-Nummer: <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-11016">CVE-2020-11016</a>. Bernhard Herzog von Intevation fand im IntelMQ-Manager, dem Web-Frontend zu IntelMQ eine Command-Injection Schwachstelle, die im schlimmsten Fall zu einer Remote Code Execution ohne jegliche Authenfikation führen konnte. Die Lücke wurde mit dem <a href="https://github.com/certtools/intelmq-manager/releases/tag/2.1.1">Release von IntelMQ-Manager 2.1.1</a> behoben.</p>
<p>Insgesamt war im ersten Drittel von 2020 also einiges los, auch wenn der im Zuge von COVID-19 erwartete massive Anstieg von IT-Sicherheitsproblemen erfreulicherweise ausblieb.</p>
<section class="footnotes"><hr />
<ol>
<li id="fn1">
<p>Siehe z.B. <a class="uri" href="https://www.bmeia.gv.at/das-ministerium/presse/aussendungen/2020/02/cyberangriff-auf-das-aussenministerium-ist-beendet/">https://www.bmeia.gv.at/das-ministerium/presse/aussendungen/2020/02/cyberangriff-auf-das-aussenministerium-ist-beendet/</a>.<a class="footnote-back" href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Siehe dazu die Posts von <a href="https://security.googleblog.com/2018/10/modernizing-transport-security.html">Google</a>, <a href="https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/">Mozilla</a>, <a href="https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/">Microsoft</a> und <a href="https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/">Apple</a>.<a class="footnote-back" href="#fnref2">↩</a></p>
</li>
<li id="fn3">
<p>Siehe dazu <a class="uri" href="https://blog.chromium.org/2019/10/chrome-ui-for-deprecating-legacy-tls.html">https://blog.chromium.org/2019/10/chrome-ui-for-deprecating-legacy-tls.html</a>, <a class="uri" href="https://www.mozilla.org/en-US/firefox/74.0/releasenotes/#note-788289">https://www.mozilla.org/en-US/firefox/74.0/releasenotes/#note-788289</a> und <a class="uri" href="https://blogs.windows.com/msedgedev/2020/03/31/tls-1-0-tls-1-1-schedule-update-edge-ie11/">https://blogs.windows.com/msedgedev/2020/03/31/tls-1-0-tls-1-1-schedule-update-edge-ie11/</a>. Von Apple gab es zum Zeitpunkt der Veröffentlichung dieses Blogposts noch keine Informationen, allerdings waren TLS 1.0 und 1.1 auf unseren Apple-Geräten noch aktiv.<a class="footnote-back" href="#fnref3">↩</a></p>
</li>
<li id="fn4">
<p>Siehe dazu den <a href="https://blog.rapid7.com/2020/04/06/phishing-for-system-on-microsoft-exchange-cve-2020-0688/">Blogpost von Rapid7</a>.<a class="footnote-back" href="#fnref4">↩</a></p>
</li>
</ol>
</section>CERT.at2020-05-12T11:15:00ZWartungsarbeiten Montag, 4. 5. 2020, 19hCERT.at2020-05-04T16:04:24Z2020-05-04T15:55:00Z<p class="block">Heute, Montag, 4. Mai 2020, ab etwa 19:00, werden wir dringende Wartungsarbeiten (ausserhalb des regulären Wartungsfensters, vgl. <a title="https://www.cert.at/services/blog/20170609114214-2029.html" href="https://www.cert.at/services/blog/20170609114214-2029.html" target="_blank">https://www.cert.at/services/blog/20170609114214-2029.html</a>) an unserer Infrastruktur vornehmen. Dies wird zu kurzen Ausfällen der extern erreichbaren Services (z.B. Mail, Webserver, Mailinglisten, Datenfeeds) führen, diese können jeweils mehrere Minuten andauern. Es gehen dabei keine Daten (z.B. Emails) verloren, die Zustellung kann sich allerdings leicht verzögern.</p>
<p class="block">Da die Wartungsarbeiten ausserhalb unserer regulären Service-Zeiten (im Wesentlichen Mo-Fr 8-18h, siehe auch <a title="https://cert.at/about/contact/contact.html" href="https://cert.at/about/contact/contact.html" target="_blank">https://cert.at/about/contact/contact.html</a>) vorgenommen werden, ändert sich bei der Bearbeitung "normaler" Vorfälle dadurch nichts.</p>CERT.at2020-05-04T15:55:00ZIn eigener Sache: CERT.at/nic.at sucht Verstärkung (Research Engineer Internet, Vollzeit)CERT.at2020-10-22T10:19:12Z2020-04-20T09:36:00Z<p class="block">Unser Research- & Developmentteam sucht für ein Projekt mit CERT.at und Security-Bezug eine/n Research Engineer (m/w, Vollzeit mit 38,5 Stunden) zum ehestmöglichen Einstieg. Dienstort ist Wien.</p>
<p class="block">Details finden sich auf der <a title="nic.at Jobs research-engineer-032020" href="https://www.nic.at/de/jobs/research-engineer-032020">nic.at Jobs-Seite</a>.</p>
<hr />
<p class="block">This blog post is part of a series of blog posts related to our <a href="https://ec.europa.eu/inea/en/connecting-europe-facility/cef-telecom/2018-at-ia-0111">CEF Telecom 2018-AT-IA-0111</a> project, which also supports our participation in the CSIRTs Network.</p>
<p class="block"><img src="https://cert.at/media/files/news/blog/202002051545/en_cef-1024x146.png" alt="Co-financed by the European Union Connecting Europe Facility" width="1024" height="146" /></p>CERT.at2020-04-20T09:36:00ZCVE-2020-0688: Verwundbare Microsoft Exchange Server in ÖsterreichCERT.at2020-04-10T10:21:33Z2020-04-10T10:25:00Z<p class="block">Mit CVE-2020-0688 wurde im Februar eine Lücke in Microsoft Exchange Servern gepatched, die AngreiferInnen ermöglicht, beliebigen Code über das Netzwerk auszuführen -- und das mit <code>NT Authority\SYSTEM</code> also der Windows-Entsprechung von <code>root</code>. Für eine erfolgreiche Attacke werden zwar gültige Zugangsdaten für einen Mailaccount benötigt, da es bei CVE-2020-0688 aber auch zu einer Privilegieneskaltion kommt, können diese auch unpriviligiert sein. Sollten also auch nur die Login-Daten einer einzigen Person mit einem Postfach am Exchange Server gestohlen werden, können Kriminelle den gesamten Server übernehmen.</p>
<p class="block">Da mittlerweile Exploits für diese Lücke öffentlich verfügbar sind,<a id="fnref1" class="footnote-ref" href="#fn1"><sup>1</sup></a> wollten wir überprüfen, wie die Patch-Situation in Österreich aussieht. Zu diesem Zweck haben wir mit Hilfe von <a href="https://www.shodan.io">shodan.io</a> eine Liste aller IP Adressen erstellt, die dessen Metriken als Exchange Server klassifizieren. Anschließend haben wir daraus jene ausgewählt, die Port 25/TCP und Port 443/TCP offen haben und sie mit einem Testscript von CERT.LV, dem nationalen CERT Lettlands, auf Verwundbarkeit getestet.<a id="fnref2" class="footnote-ref" href="#fn2"><sup>2</sup></a> Dieser Test überprüft nur den Versionsstring des Exchange Servers, der in der URL enthalten ist, wenn eine Nutzerin oder ein Nutzer das OWA Interface aufrufen. Anschließend haben wir alle, deren Exchange Server die Updates noch nicht eingespielt haben, darüber informiert.</p>
<p class="block">Insgesamt gab es zum Zeitpunkt unserer Suche laut Shodan 4501 Exchange Server in Österreich, von denen das Script von CERT.LV 1096 als ungepatched identifizierte. Diese verteilen sich folgendermaßen auf die betroffenen Exchange Versionen:</p>
<ul>
<li class="block">Exchange Server 2013: 245</li>
<li class="block">Exchange Server 2016: 767</li>
<li class="block">Exchange Server 2019: 84</li>
</ul>
<p class="block">Wir werden diesen Scan in einiger Zeit wiederholen und hoffen, dass sich die Zahlen dann verringert haben.</p>
<section class="footnotes"><hr />
<ol>
<li id="fn1">
<p>Vgl. z.B. <a href="https://github.com/Ridter/cve-2020-0688">https://github.com/Ridter/cve-2020-0688</a>, <a href="https://github.com/Yt1g3r/CVE-2020-0688_EXP">https://github.com/Yt1g3r/CVE-2020-0688_EXP</a> und <a href="https://github.com/Jumbo-WJB/CVE-2020-0688">https://github.com/Jumbo-WJB/CVE-2020-0688</a>.<a class="footnote-back" href="#fnref1">↩</a></p>
</li>
<li id="fn2">
<p>Diese findet sich ebenfalls auf GitHub, unter <a href="https://github.com/cert-lv/CVE-2020-0688">https://github.com/cert-lv/CVE-2020-0688</a>.<a class="footnote-back" href="#fnref2">↩</a></p>
</li>
</ol>
</section>CERT.at2020-04-10T10:25:00ZJahresbericht 2019 von CERT.at und GovCERT Austria veröffentlichtCERT.at2020-04-08T15:30:23Z2020-04-08T15:30:00Z<p class="block">Das Mandat als nationales Computer-Notfallteam nach NISG, Emotet, Ransomware, Sextortion, ein Projektabschluss und CberExchanges – das Jahr 2019 war für CERT.at und GovCERT Austria ein ereignisreiches, das wir in Form unseres Jahresberichts Revue passieren lassen. Die HTML-Version finden Sie unter <a href="https://cert.at/de/berichte/2019/">https://cert.at/de/berichte/2019/</a>, wenn Sie das PDF-Format bevorzugen, finden Sie die entsprechende Datei auf <a href="https://cert.at/de/downloads/berichte/jahresbericht-internet-sicherheit-osterreich-2019">https://cert.at/de/downloads/berichte/jahresbericht-internet-sicherheit-osterreich-2019</a>.</p>
<p class="block">An dieser Stelle auch noch ein herzliches Dankeschön an Jana Wiese (<a href="https://twitter.com/jasowies_o">@jasowies_o</a>), die unsere Arbeit mit zwei Sketchnotes im Bericht zeichnerisch zusammengefasst hat.</p>CERT.at2020-04-08T15:30:00ZDie Shadowserver Foundation braucht dringend finanzielle HilfeCERT.at2020-03-17T07:09:05Z2020-03-17T07:10:00Z<p class="block">Die Shadowserver Foundation ist nicht nur weltweit die größte Quelle von Threat Intelligence, sie ist auch bei weitem die wichtigste Informationsquelle für CERT.at zu Themen wie Malwareinfektionen, verwundbaren Systeme, etc. in Österreich (siehe <a href="https://cert.at/de/services/daten-feeds/shadowserver/">die Liste der Feeds, die wir von Shadowserver erhalten</a>). Insgesamt versorgt die Shadowserver Foundation 107 nationale CERTs/CSIRTs in 136 Ländern mit wertvollen Informationen über Probleme in ihrem jeweiligen Einflussgebiet. Die Qualität der so zur Verfügung gestellten Daten liegt weit über jener der meisten anderen, obwohl sie vollständig kostenlos zur Verfügung gestellt werden.</p>
<p class="block">Im Februar hat Cisco Systems, die bisher das Rechenzentrum sowie Personal für die Shadowserver Foundation zur Verfügung stellten, überraschend bekanntgegeben, dass sie leider nicht mehr in der Lage sind, dieses Angebot aufrecht zu erhalten und angegeben, dass die Shadowserver Foundation bis 26. Mai Zeit hat, ihr gesamtes Rechenzentrum an einen anderen Ort zu übersiedeln. Das kostet natürlich viel Geld und übersteigt die Liquidität dieser – gerade im Vergleich zu ihrer Wichtigkeit extrem kleinen – NPO bei weitem und sie hat daher einen Hilferuf gestartet, um ihr Weiterbestehen finanzieren zu können.</p>
<p class="block">Wenn Sie in Ihrem Unternehmen noch Budget übrig haben, ist das sicherlich eine der besten Möglichkeiten, es einzusetzen – das gesamte Internet wird es Ihnen danken.</p>
<p class="block">Weiterführende Informationen finden Sie auf der Webseite der Shadowserver Foundation:</p>
<p class="block"><a href="https://www.shadowserver.org/news/saving-shadowserver-and-securing-the-internet-why-you-should-care-how-you-can-help/">https://www.shadowserver.org/news/saving-shadowserver-and-securing-the-internet-why-you-should-care-how-you-can-help/</a></p>CERT.at2020-03-17T07:10:00ZIn eigener Sache: CERT.at sucht Verstärkung (Software Entwickler für Open-Source Projekt, Teil-/Vollzeit)CERT.at2020-10-22T10:20:11Z2020-03-05T16:46:00Z<p class="block">Für unser international renommiertes Open-Source Projekt IntelMQ suchen wir eine/n Software Entwickler/in (Teil- oder Vollzeit 25-38,5 Stunden) zum ehestmöglichen Einstieg. Dienstort ist Wien.</p>
<p class="block">Details finden sich wie immer auf unserer <a href="https://cert.at/de/ueber-uns/jobs/">Jobs-Seite</a>.</p>CERT.at2020-03-05T16:46:00Z