Kategorie: Themen

Corona

Wo bleibt die Excel-ends-Initiative? MS Excel frisst Corona-Daten

Beim britischen Gesundheitssystem sind mehrere tausend Datensätze zu positiven Corona-Tests verloren gegangen, da das alte Excel-Dateiformat .xls nur eine begrenzte Anzahl von Zeilen speichern kann. Der Fehler fiel erst nach mehreren Tagen auf, sodass Betroffene teilweise erst sehr spät benachrichtigt werden konnten.

Das Problem unsicherer „Schatten-Softwareentwicklung“ durch Endnutzer in Office-Tools, insbesondere Excel, ist seit vielen Jahren bekannt und nicht leicht in den Griff zu bekommen.

https://t3n.de/news/excel-verursacht-corona-panne-1326375

Security-Kolumne „Spreadsheets töten“ in aktueller iX: https://www.heise.de/select/ix/2020/11/2026109274934915903

Ransomware

Totgecybert? Kollateralschäden von Ransomware

Ein eventuelles erstes Todesopfer eines Cyberangriffs in Deutschland hat die Debatte um Kritische Infrastrukturen und IT-Sicherheit in Krankenhäusern aufgeschreckt. Ein fehlgeleiteter Ransomware-Angriff auf das Uniklinikum Düsseldorf – es sollte eigentlich „nur“ die Universität treffen – hat zum Shutdown des Krankenhausbetriebs geführt. Obwohl die in Russland vermuteten Täter der Gruppe DoppelPaymer nach Mitteilung des Irrtums durch die Polizei umgehend die Schlüssel herausrückten, um das Krankenhaus wieder in Gang zu bringen, laufen nun Ermittlungen wegen des Verdachts der fahrlässigen Tötung einer Patientin, die statt in die nahe Uni-Klinik in ein weiter entferntes Krankenhaus gebracht worden und gestorben war. Ein eventuelles Gerichtverfahren wäre Neuland und ein möglicher Präzedenzfall für den Umgang mit Angriffen auf Kritische Infrastrukturen. Ähnlich wie bei anderen aktuellen Themen – etwa den Mordanklagen gegen Raser – bewegen sich hier nicht nur Ermittlungsbehörden, sondern auch Gerichte auf dünnem Eis. Gleichzeitig dürfte die Auseinandersetzung mit dem und über das Thema entscheidend mitgestaltend daran sein, wie wir als Gesellschaft Verantwortung und Rechenschaft im Internet sehen, leben und verfolgen wollen.

https://www.heise.de/news/Uniklinik-Duesseldorf-Ransomware-DoppelPaymer-soll-hinter-dem-Angriff-stecken-4908608.html

Netzwerk

Securing DNS Traffic: An Introduction to DoT & DoH

In recent times, operating systems including Windows and macOS have been adding support for encrypted DNS. But how do the involved protocols work? And what are their benefits?

To understand them, we first have to look at the Domain Name System (DNS) itself, which is one of the fundamental backbones of the Internet. However, DNS alone does not provide any encryption or authentication, which makes DNS communication vulnerable to eavesdropping and in-transit modifications. Adversaries can use DNS information in cache poisoning attacks to lure victims on phishing websites. On a larger scale, state-level agencies can use pervasive monitoring of DNS for surveillance purposes and therefore attack users‘ privacy. Other third parties can use DNS data for Open Source Intelligence (OSINT) purposes, which may harm users‘ security altogether.

Timeline of DNS history

Encrypted DNS protocols were first introduced in 2008 when Daniel J. Bernstein proposed DNSCurve. In the following years DNSCrypt followed but both protocols failed to gain noteworthy adoption. In hindsight of the Snowden revelations in 2013, DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) were developed and standardized by the IETF. They aim to secure DNS by adding confidentiality, integrity and server authenticity.

But how do these protocols work? Let’s have a short look at each.

DNS-over-TLS

DoT, described in RFC 7858, is using the well-known Transport Layer Security (TLS) protocol and thus inherits all its security benefits. By default, DoT resolver listen on port 853 for incoming DNS queries that must be encrypted. This non-standard port was chosen to ease the differentiation between DoT and non-DoT connections. However, administrators deploying DoT can choose a different port, provided that both resolver and clients agree. A fallback to cleartext DNS messages within the protocol is not allowed, neither for the client nor the server.

DoT protocol

The protocol, as shown above, consists of two Round-Trip Times (RTT) on first contact. First, the DNS client performs the TCP handshake with the resolver it has chosen to connect to. Next, the DNS client performs the TLS handshake with the server. The client does not necessarily have to authenticate the server as this depends on the used profile. Therefore, self-signed certificates are also acceptable. After the successful completion of the handshake, both parties obtain a session key that is used for subsequent packets. In a third step, the DNS client sends its DNS queries through the established TLS channel. Multiple DNS queries may be pipelined to reduce bandwidth. Messages sent through this TLS channel are hidden from any intermediate party; therefore the DNS queries and answers stay confidential, with any Manipulation detectable.

Privacy Profiles

DoT supports two usage profiles that are defined in RFC 8310 and differ in the privacy they provide. Clients can choose which profile to follow and can thus match their DNS settings to their requirements. Administrators can also force the use of a usage profile.

  • Opportunistic: This profile does not guarantee privacy but tries to achieve as much as possible. Therefore, if connections to servers cannot be authenticated or encrypted they are still acceptable for the client. This profile consciously rates availability as a primary and privacy as a secondary goal and can thus result in insecure connections.
  • Strict: This is a privacy-oriented profile and does not allow establishment of connections to servers that cannot be encrypted or authenticated. It restricts availability but guarantees privacy of DNS messages. A fallback to insecure connections is prohibited.

Use of the strict privacy profile is recommended to establish adequate security in most settings.

DNS-over-HTTPS

DoH, as described in RFC 8484, is the most recent standard for encrypted DNS and uses HTTPS sessions to exchange DNS messages. This enables masking within other HTTPS traffic.
DoH uses URI templates to send DNS requests and can either use GET or POST methods. When using Cloudflare’s 1.1.1.1 resolver, the requests are structured as followed:

  • The GET request is sent to https://1.1.1.1/dns-query?dns, where the value of the DNS parameter contains the DNS message encoded in base64url.
  • The POST request is sent to https://1.1.1.1/dns-query within the message body. In addition, the header application/dns-message is specified.

It is interesting to note that the RFC does not specifiy the path dns-query. However, lists of public resolvers show that resolvers generally follow this format. Web browsers are able to conduct the requests on their own as they ship with an HTTP engine. An example GET request that recursively resolves the domain name www.hisolutions.com is shown below:

https://1.1.1.1/dns-query?dns=AAABAAABAAAAAAAAA3d3dwtoaXNvbHV0aW9ucwNjb20AAAEAAQ

The answer includes the corresponding IPv4 address of the resolved domain. For more information about the structure of DNS messages, refer to RFC 1035.

DoH protocol

Overall, the DoH protocol works similar to DoT. Their protocol messages include the same content, except for the additional wrapping of DoH messages. However, this wrapping in combination with operating on the same port as common web traffic yields additional privacy benefits that are discussed below.

Discussion

DoH offers the best privacy guarantees of the encrypted DNS protocols. The use of the common port 443 could help prevent censorship of DNS lookups, as third parties observing the traffic are not able to differentiate between regular web and DNS traffic. Therefore, they must block access to the full website to block DNS lookups. A blacklist only works partially as it can only block the access to well-known DoH resolvers. Another point includes the additional masquerading of DNS messages through the use of HTTP. This decreases the likelihood of successful fingerprinting through observing third parties. On the other side, DoT does not interfere with common web traffic by operating on a dedicated port. This enables adversaries to simply drop traffic on that port, such that clients must switch to an (insecure) alternative. However, in managed environments this may be done on purpose, e.g. to force the use of predefined resolvers.

Both protocols add a performance overhead compared to traditional DNS. Although researchers found higher response times for individual DoT/DoH queries, page load times performed similar to traditional DNS given stable network connections. When network conditions degraded, traditional DNS significantly outperformed DoT/DoH. However, this is critique on a high level and the elevated response time is rarely noticeable on the user side.

Usability of both protocols has increased over time, and further adoptions are already planned. As of now, DoT/DoH is already available in Firefox, Chrome and Opera, and therefore supported in the most common web browsers. When it comes to operating systems, both Windows and macOS have added DoH to their pre-release channels and are planning to release it anytime soon. On mobile, Android has been supporting DoT since Android 9. Overall, users are mostly able to enable encrypted DNS on their devices.

We performed some measurements on the Internet and found that, while the number of users of DoH has increased significantly over time, the number of DoH resolvers has not. This highlights a consolidation in the DNS resolver market, which can be problematic in case of untrustworthy resolvers. Even for trustworthy ones, it introduces a single point of failure that other systems rely on, as a recent Cloudflare outage showed. Therefore, the defined secondary resolver should not be of the same provider as the primary one. When using open resolvers we recommend the use of resolvers that have clear privacy directives, prove successful third party audits and have a clean compliance history.

In the future, other encrypted DNS protocols such as DNS-over-QUIC (DoQ) may be used as well. They will probably increase in adoption once HTTP/3 starts rolling out, but DoQ does not include additional privacy benefits as long as most web traffic is still conducted over HTTPS.

Advisories, Ransomware

Warnung: Aktuelle Ransomware-Angriffe als Folge von Shitrix

Monate nach dem Auftauchen der kritischen Sicherheitslücke im Citrix Application Delivery Controller (ADC) und NetScaler Gateway (CVE-2019-19781, auch als “Shitrix“ bekannt) werden nun immer mehr Fälle bekannt, in denen die Lücke früh ausgenutzt, jedoch erst sehr viel später lukrativ verwendet wurde bzw. aktuell wird.

Unsere Incident Responder stellten dabei fest, dass im kritischen Zeitraum Anfang 2020 in einigen Fällen Backdoors installiert worden sind, welche nun, 8 Monate später, durch Ransomware-Angriffe aktiv ausgenutzt werden.

Details im HiSolutions Advisory von Folker Schmidt und Daniel Jedecke.

Advisories, Ransomware

Warning: Current Ransomware Attacks As a Result of Shitrix

By Folker Schmidt and Daniel Jedecke

Months after the appearance of the critical vulnerability in Citrix Application Delivery Controller (ADC) and NetScaler Gateway (CVE-2019-19781, also known as „Shitrix“), more and more cases are now becoming known where the vulnerability was exploited very early on, but was not used for extortion until much later, and ongoing.

Our incident responders found that in a critical period in early 2020, backdoors were installed in some cases, which are actively exploited now, 8 months later, for ransomware attacks. In many cases, the attackers have not even bothered to adapt the known proofs-of-concept of the „Project Zero India“ group. In the cases known to us, the user „pwnpzi1337“ was created, which was used in the original PoC.

The subsequent steps of the attack are basically the same as they were before, network discovery, lateral movement within the network (for example using Dridex or Cobalt-Strike), data exfiltration, and later encryption of the data e.g. via DoppelPaymer.

However, there is a multitude of other conceivable malware variants on the market. Due to the current wave of attacks, every administrator and system administrator is strongly recommended to check their Citrix NetScaler systems in particular for possible new users or conspicuous network activity. A check of the folder /var/vpn/bookmark is definitely recommended, since the XML files smuggled in by the attacker can be found there. As a quick check for possible compromise, the instructions under http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781 have proved to be helpful.

If there is any doubt about the integrity of the system, our forensic experts recommend rebuilding the system, which is the standard procedure for ransomware attacks. We are happy to refer to the recommendations of the German BSI (Federal Cyber Security Agency). Back in January 2020, the BSI issued a Citrix vulnerability warning (see CSW No. 2020-172597-1531, Version 1.5, 30.01.2020 and https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2020/Citrix_Schwachstelle_160120.html), which contains, among other helpful bits, the following measures:

  • Disconnection from network of the compromised Citrix instance
  • Backup of the old Citrix instance (entire system, or at least the log files under /var/log/*)
  • Restart of Citrix instance with the latest build of the respective version branch and implementing the workaround (workaround recommendation when no patches were available yet)
  • Creation of new SSL/TLS certificates, recall of old SSL/TLS certificates
  • Resetting of all Windows Active Directory passwords if the Citrix user group cannot be restricted
  • Depending on the network connection, check the Windows domain for further compromises
  • If wildcard SSL certificates (*.example.com) were used on a compromised Citrix system, all other systems using the wildcard certificate must be taken into account in the certificate exchange mentioned above.

Citrix administrators should always subscribe to Citrix security bulletins with notices of new firmware versions to receive information about new firmware updates

The German Alliance for Cyber Security has recommended further action. These can be found at https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/Ransomware/Ransomware_Massnahmenkatalog.html.

It is also important to note in this case that the attackers could potentially move around the network unnoticed for months, which could jeopardize the integrity of backups that have been made long ago. Special care must be taken here when restoring affected systems.

At the beginning of August 2020, still around 200 vulnerable Citrix systems in Germany were accessible from the Internet (https://twitter.com/certbund/status/1291017699351580675). The number of systems that are secured but have already implemented a backdoor cannot be quantified.

Allgemein, Schwachstelle

Web vulnerabilities are coming to the Desktop again – RCEs and other vulnerabilities in Teamwire

TL;DR (Teamwire users): Multiple vulnerabilities have been found in Teamwire which allow malicious users to execute commands on victim’s computers. Upgrade Teamwire to the newest version (at least v2.5.0 as of Jan 21, 2021) as soon as possible to fix the vulnerabilities.

TL;DR (Technical): Cross-site-scripting and HTML injections are common vulnerabilities in web applications. If a desktop application, like the Teamwire Windows client, builds on a web engine which is vulnerable to these issues, this can result in remote code execution on the client systems.

Vulnerability Summary

A HiSolutions researcher discovered that code could be executed in other users clients if a crafted message was shown in their search results (CVE-2024-24275). Another vulnerability in the handling of pasted text (CVE-2024-24278) and potential issues that allowed for the injection of sanitized HTML-elements (CVE-2024-24276) were found and reported to Teamwire.
Teamwire replied back that the issues were independently found in an internal security audit a few weeks before and released a new Teamwire version within a day.
When HiSolutions reviewed this new version, it was discovered that only a part of the reported vulnerabilities were fixed. Furthermore, the previously identified RCE (CVE-2024-24275) vulnerability could be exploited again in this version, just slightly different this time. In the new version, code was executed when an attacker created a group with a specially crafted name and invited victims to the group as well as in any other places where the group name was shown (e.g. search results or group directory).

Background

Teamwire uses different technologies for their Windows desktop client that contained the below mentioned vulnerabilities. The client is based on NW.js. As written in our last article about a different set of Teamwire vulnerabilities:

NW.js is a technology that combines the browser engine WebKit with the JavaScript framework Node.js, and is often used to create cross-platform applications. This combination enables users to call Node.js functions directly from the DOM of the embedded Chromium browser.

The application itself then uses, among other technologies, AngularJS for client side JavaScript functionality.

Vulnerability Details

Desktop client RCE through search results (CVE-2024-24275)

In versions below 2.3.0 of the Teamwire Windows desktop client, when a message that contained HTML code was shown inside the search results, this HTML code was embedded inside the client without any sanitization or encoding. Any included HTML elements were rendered and JavaScript code executed, allowing for arbitrary code execution. This issue affected both the chat and the global search function. Through NodeJS functions, commands could be executed directly on the operating system of the victim.

If the attacker created an arbitrary group, posted messages similar to:

<img src=x onerror="const spawn=require('child_process').spawn;spawn('cmd.exe',['/c','calc.exe']);console.log(1);//Something searchword">

and invited a victim, the payload was planted inside the client application. When a victim then did a search (inside the chat or global search) for a word matching any of the additionally supplied words (see text in red in payload), the code was executed on the client system. For demonstration purposes, the program calc.exe was opened but any actions inside the application or on the system would have been possible.

Screenshot of the calc.exe program that was executed when JavaScript code embedded in a message from the attacker was executed after it matched the search of a victim.

The underlying reason for this behaviour seemed to be the function that normally provided the highlighting of the search words (angular.module("Teamwire.filters").filter("highlight",…). This function did not sanitize, filter or encode the messages in the search results before using the AngularJS function trustAsHtml and embedding the result. Any included HTML elements were therefore rendered and any contained JavaScript code executed.

This behaviour affected the versions of the Teamwire Windows desktop client between version numbers 2.0.1 and below 2.3.0. Older versions may be affected as well.
The vulnerability was fixed in version 2.3.0.
However, version 2.3.0 was affected in another way by the following vulnerability.

Desktop client RCE through list names (also tracked under CVE-2024-24275)

In version 2.3.0 of the Teamwire Windows desktop client, group names were embedded inside the client without any sanitization or encoding. Any included HTML elements were rendered and JavaScript code executed in multiple places, allowing for arbitrary code execution. Through NodeJS functions, commands could be executed directly on the operating system of the victim.

If the attacker created a group with the name

<img src=x onerror="const spawn=require('child_process').spawn;spawn('cmd.exe',['/c','calc.exe']);console.log(1);//Something">

and invited the victims, the code was executed on the client systems. For demonstration purposes, the program calc.exe was opened but any actions inside the application or on the system would have been possible.

Screenshot of the program calc.exe that was opened for demonstation purposes.

The injected code was executed at least in the following places:

  • When a user viewed the tab „Directory“ and then „Lists“ and was added to the malicious group by the attacker
  • When a user used the global search and the malicious group name matched the search word
  • When a user viewed the members of a group chat that contained the malicious group as a member
  • When a user wanted to create a new group chat and the malicious group was an element in the „Lists“ directory

This behaviour affected version 2.3.0 of the Teamwire Windows desktop client. Older versions were not affected.
The vulnerability was fixed in version 2.4.0.

Automatic UNC path resolution in pasted text (CVE-2024-24278)

If a user pasted text into the message area of the Teamwire Windows client and that text matched a UNC path, the Teamwire client automatically tried to connect to the system and proceeded to authenticate via SMB with the current Windows logon credentials. An attacker inside the internal network could use this vulnerability to capture hashed credentials or redirect the user authentication attempt to other systems.

For example: If a user pasted the text „\\192.168.194.133\something\test.docx“ into the message field, the client tried to access the SMB share on the system 192.168.194.133 immediately without showing the pasted text first.

This behaviour would be expected if a client would click on a link or open the path in the Windows explorer. It is however not expected if a user only pastes the text without submitting it or initiating any other action. Especially if a user copies text from a web page, where malicious content could be hidden by CSS, unintended text might be pasted into the application. The pasted content is only shown after the connection to the specified share was already established.

This behaviour affected all versions of the Teamwire Windows desktop clients between version numbers 2.0.1 and 2.4.0. Older versions may be affected as well. A newer version than 2.4.0 may include a fix but was not tested.

Injection of sanitized HTML elements in multiple places (CVE-2024-24276)

At least four instances inside the Teamwire Windows client were identified, where user supplied HTML code was rendered inside the application. The HTML code however, was sanitized by the AngularJS sanitize$ function, which prevented the insertion of malicious JavaScript code. An attacker would need to find a bypass for this function to elevate these issues into remote code exection vulnerabilities.
Without such a bypass, only harmless modifications like manipulation of the application appearance or embedding of external images was possbile.

The four identified instances were:

  1. When an administrator renamed a chat, the new name was sent to all members of the group and the sanitized HTML was rendered
    Screenshot of HTML injection inside new group name
  2. The message preview when a user answered another message
    Screenshot of HTML injection in message answer preview
  3. When a user with a manipulated name was removed from a group
    Screenshot of HTML injection when malicious user is removed from a chat
  4. When an administrator tried to leave a chat that still contained a group of which he was a member

This behaviour affected all versions of the Teamwire Windows desktop clients between version numbers 2.0.1 and 2.2.1. Older versions may be affected as well.
Instances 2 and 4 were fixed in version 2.3.0.
Instances 1 and 3 still exist in 2.3.0 and possibly later versions as well.

Disclosure Timeline

  • 25. August 2020 – HiSolutions reaches out to Teamwire to establish secure, encrypted communication via email so that vulnerability details can be sent
  • 25. August 2020 – Teamwire provides a contact and the corresponding PGP key
  • 25. August 2020 – HiSolutions sends the vulnerability details for the three vulnerabilities CVE-2024-24275, CVE-2024-24276, CVE-2024-24278
  • 26. August 2020 – Teamwire responds that the mentioned issues were internally discovered a few weeks before and releases a new Teamwire version 2.3.0 that is supposed to contain the fixes
  • 26. August 2020 – HiSolutions tests the new version
  • 27. August 2020 – HiSolutions sends the details of the retest and the new vulnerability to the Teamwire contact
  • 16. October 2020 – Teamwire publishes version 2.4.0 which includes fixes for some of the vulnerabilities
  • 2020/2021 HiSolutions can no longer assess Teamwire and pauses the responsible disclosure process
  • 16. January 2024 – HiSolutions publishes the vulnerability details after a sufficient grace period

Credits

The vulnerabilities were found by Denis Werner (HiSolutions AG) who also reviewed the fixes.

KI/ML

Hier bin ich, Mensch, hier schreib ich’s rein: KI textet täuschend echt

Dieser Digest wurde für Sie wie immer von David Fuhr und diesmal auch Robert Waniek geschrieben. Sicher? Sind wir uns selbst ganz sicher? Die künstliche Intelligenz (KI) hat beim Verfassen von Texten jüngst die Schwelle überschritten, vor der sie durch uns Menschen leicht als Maschine zu erkennen war. Das maschinell an Millionen von Texten trainierte Modell GPT-3 des von Tesla-Gründer Elon Musk und Microsoft finanzierten Unternehmens Open AI kann Texte unterschiedlicher Art produzieren, welche oft auf den ersten und zweiten Blick nicht von denen menschlicher Autoren zu unterscheiden sind. 
Neben einer riesigen Menge nützlicher bis lustig-alberner oder auch sinnloser Anwendungsszenarien fallen in Security-Denke geschulten Zeitgenossen sofort mögliche Missbrauchsszenarien ein. Wie viel besser kann hiermit das Schreiben täuschend echter Phishing-Mails skaliert werden? Wie viel vertrauenswürdiger können nigerianische Prinzen wirken, wenn sie jede/n Autor/-in und jeden Stil perfekt imitieren können? Und wie sehr können wir der Wahrheit noch trauen, wenn jeder sie auf Knopfdruck mit einem Meer von Fiktion überschwemmen kann?
Noch ist die KI mit ihren eigenen Mitteln leicht zu schlagen, und die Fälschungen sind technisch gut zu erkennen, wenn man denn weiß wie und den Aufwand betreibt. Aber diese Kinderkrankheiten werden im üblichen Katz- und Maus-Spiel bald immer weiter ausgemerzt. Wir tun gut daran, uns bei Texten schon heute langsam einen wachsenden Skeptizismus anzutrainieren, wie wir dies auch mit Bildern lernen mussten und zukünftig verstärkt alternative Herkunfts- und Wahrheitsbeweise einzufordern, wie wir es etwa in der Kryptografie tun.

https://www.spiegel.de/netzwelt/web/gpt-3-die-eloquenteste-kuenstliche-intelligenz-der-welt-a-dd3b3423-d214-4a2f-bc51-d51a2ae22074

Cloud, Incidents

OAuth-Phishing

Im Rahmen von COVID-19 wurden viele neue Phishing-Kampagnen verzeichnet – darunter auch sogenannte OAuth-Phishing-Angriffe gegen Office 365. Hierbei werden Phishing-Mails an Benutzer gesendet, die, wenn sie auf den in der Mail enthaltenen Link klicken, gefragt werden, ob sie Berechtigungen an eine App übergeben wollen. Mit der Bestätigung autorisiert der Benutzer dann die App für den Zugriff auf seine Daten. Der Ablauf des OAuth-Phishings ist in der untenstehenden Abbildung dargestellt.

Ablauf OAuth-Phishing

Doch die Vorgehensweise ist nicht neu. Bereits 2017 kam es zu einer großen Phishing-Welle, die Google Docs-Benutzer dazu einlud, ein geteiltes Dokument aufzurufen. Für diese Angriffe mittels OAuth-Apps werden die Funktionalitäten des OAuth-Protokolls genutzt. Mit OAuth kann ein Benutzer einer Anwendung den Zugriff auf seine Daten erlauben, die von einem anderen Dienst bereitgestellt werden. Der Zugriff der Anwendung erfolgt dabei ohne Benutzerkennung und Passwort. Somit können auch eine Passwortänderung oder die Einführung einer Multifaktorauthentifizierung die Vergabe der Berechtigungen nicht mehr rückgängig machen.

Es wird hier also keine Schwachstelle im OAuth-Protokoll ausgenutzt. Stattdessen wird der Benutzer dazu gebracht, Berechtigungen zu übergeben, ohne dass ihm dies bewusst ist. Hierzu werden Links mit zu Office 365 oder Google G Suite ähnlich klingenden Domainnamen verwendet, und auch die App-Namen werden so gewählt, dass ein unbedarfter Benutzer diese mit dem jeweiligen Cloud-Dienst assoziiert.

Ein OAuth-Phishing-Angriff ist im Nachhinein schwer erkennbar, da kein schadhafter Code ausgeführt wird. Stattdessen können Daten gelesen und je nach Berechtigung auch geändert oder gelöscht werden. So kann ein Angriff unbemerkt bleiben oder wird erst dann bemerkt, wenn in einer weiteren Angriffsphase Daten verschlüsselt wurden oder ein CEO-Fraud begangen wurde.

Damit es erst gar nicht zu einem Zugriff mittels OAuth-Phishing kommt, sind folgende Maßnahmen zu empfehlen:

  1. Schulung der Mitarbeiter, um OAuth-Phishing-Angriffe zu erkennen
  2. Drittanbieter-Apps nur mittels Whitelisting zulassen oder die Nutzung ganz untersagen
  3. In Office 365 können Drittanbieter-Apps mittels der CASB-Lösung von Microsoft (Cloud App Security) überwacht werden. Dieses Feature steht jedoch nur in der E5-Lizenz zur Verfügung.

Falls man vermutet, dass man mittels einer OAuth-App kompromittiert wurde, dann kann man dies in Office 365 über das von Microsoft für Office 365 veröffentlichte Vorgehen[1] nachvollziehen und die Berechtigungen der jeweiligen App deaktivieren. Grundsätzlich sollte die verdächtige App deaktiviert werden und es sollten die Berechtigungen entzogen werden. Anschließend sollten die Zugriffsprotokolle überprüft werden, um den Umfang der Kompromittierung zu verstehen.

[1] https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants

Malware

Malen ohne war einmal: Malware für Macs

Es hat sich über die letzten Jahre langsam herumgesprochen: Auch für Apples macOS gibt es Schadsoftware. So kommt es nicht unerwartet, dass sich auch bei Mac-Malware steigende Softwarequalität durchsetzt. Ein Ransomware-Schädling namens EvilQuest verbreitet sich derzeit über Raubkopien und Software-Updates aus fragwürdigen Quellen. Eine kostengünstige Entsperrung der verschlüsselten Daten wird bereits für 50 US-Dollar in Bitcoin angeboten. Doch der Service Gedanke trügt: Die Ransomware ist nur ein Puzzleteil einer umfangreichen Supply-Chain.
Selbst wenn der Nutzer zahlt, endet damit nicht der Service der Schadsoftware-„Hersteller“, denn EvilQuest beherrscht auch die Suche nach Virenscannern und Tools zur Verwaltung von Kryptowährungen sowie die Installation eines Keyloggers und einer Fernsteuerung für den Angreifer (Reverse Shell). Zudem setzt sich die Malware tief im System fest und überträgt Nutzerdaten auf den Server des Angreifers.
Um derlei Risiken zu reduzieren, sollte man vertrauenswürdige Download-Quellen verwenden –sowohl bei der Installation als auch bei Updates – um die eigene Supply-Chain sauber zu halten. Denn auch wenn der macOS-interne Schutz XProtect die Malware inzwischen blockiert und gegen die mangelhafte Verschlüsselung ein Tool existiert, bleiben drei Fragen offen, die Nutzer aller Betriebssysteme vereint: Ist der Angreifer noch da? Wo sind meine persönlichen Daten? Habe ich ein aktuelles Offline-Backup meiner wichtigsten Daten?

https://www.heise.de/news/Neue-Mac-Ransomware-kursiert-in-illegalen-Kopien-4800485.html

https://www.heise.de/news/Mac-Malware-EvilQuest-ThiefQuest-Entschluesselungs-Tool-soll-helfen-4839435.html

Corona, Security Engineering

Ruck ohne Hau – Corona-Warn-App kein Security-Albtraum

Es geht diese Tage ein Ruck durch das Neuland – und zwar kein Hau-Ruck, den viele gleichwohl befürchtet hatten, als sich abzuzeichnen drohte, dass auch die deutsche Corona-Warn-App bei Datenschützenden und anderen IT-Justice Warriors von Anfang an in Ungnade stehen würde. Nun staunt der Laie – und selbst der Chaos Computer Club und sein Umfeld wundern sich: Ist die Macht der Datenverbraucherschützer wirklich so groß geworden, dass Behörden sich wandeln und plötzlich agile Open Source produzieren (lassen)? Anscheinend haben das Schreiben offener Briefe und das Führen hitziger Diskussionen in den sozialen Medien diesmal zwei Großkonzerne und mehrere Behörden dazu gebracht, in entscheidenden (auch datenschutz- bzw. sicherheitskritischen) Fragen umzusteuern. Das sind wir nicht gewöhnt!

Gezeigt hat sich auf jeden Fall schon jetzt: Die frühzeitige und umfassende Einbindung, gerade auch kritischer Kunden- und Gesellschaftsgruppen hat der Verbreitung der App zumindest nicht geschadet. Ob dies auch massenhafte Nutzung garantiert, steht auf einem anderen Blatt. Aber in einer idealen Welt wird auch dieser Prozess wie alle anderen gesellschaftlich relevanten Veränderungen von einer informierten und kritisch-produktiven Öffentlichkeit begleitet und wenn notwendig in die richtige Richtung gestupst. Auch angesichts einiger anderer Meldungen in diesem Digest: Zu Tode gesiegt hat sich die digitale Bürgerrechtsbewegung noch lange nicht.