English version below.
Hallo zusammen,
vor ca. 2 Wochen gab es einen Post auf Hacker News, in welchem ein DDoS der Betreiber von archive[.]today, auch auf diversen anderen Domains wie archive[.]ph oder archive[.]is vertreten, gemeldet wurde.
Der HN Post selber ist recht fragwürdig, wie man in den HN Kommentaren nachlesen kann, insbesondere hinsichtlich des Nutzernamens von dem das gepostet wurde, aber inhaltlich ist es zutreffend.
Der DDoS-Angriff wird als JavaScript Code im Browser von Besuchern der archive[.]today Webseiten ausgeführt. Effektiv werden damit die Geräte von Besuchern für den Cyberangriff missbraucht, was einen Block beim Ziel deutlich erschwert. Wer bewusst an einem Botnetz teilnimmt macht sich potentiell auch der Computersabotage nach § 303b StGB in Deutschland oder vergleichbaren Gesetzen schuldig.
Dies ist auch jetzt weiterhin der Fall, da beim Besuchen der CAPTCHA-Seite weiterhin JavaScript Code für den DDoS ausgeliefert wird, um die angegriffene Seite vielfach aufzurufen. Die meisten gängigen Content- und Werbeblocker wie uBlock Origin sollten dies standardmäßig rausfiltern, jedoch kann man nicht davon ausgehen, dass jede Person sowas nutzt, insbesondere auf Mobilgeräten.
Zunächst hat @eb@social.coop diesen Thread gepostet, mit zusätzlichen Details weiter unten im Thread. Konkret hier und hier.
Etwas später gab es eine weitere Meldung von @iampytest1@infosec.exchange, welcher auch zusätzlich die Betreiber per Email um eine Stellungnahme gebeten hat. Laut iam-py-test gab es eine Antwort, in welcher der Ausgang des Angriffs von archive[.]today zugegeben wird. Damit ist davon auszugehen dass es nicht nur ein Fall eines Kompromittierten Servers ist.
Da archive[.]today ein recht populärer Dienst zur Archivierung von Webseiten ist möchten wir nicht ohne Rücksprache mit der Community drastische Maßnahmen ergreifen. Wir haben in den letzten Tagen überlegt welche Maßnahmen wir hier ergreifen können und welche Auswirkungen diese haben werden:
- Hinterlegung der Domains in Lemmy's URL-Filter
Für lokale Nutzer werden Inhalte mit Links zu den betroffenen Domains nicht mehr erstellbar sein bis der Link entfernt wurde.
Inhalte von Nutzern anderer Instanzen werden bei der Föderation direkt abgewiesen und sind bei uns überhaupt nicht erst sichtbar. Bei Inhalten in unseren Communities werden die Nutzer darüber auch nicht informiert, aus deren Sicht ist es nur ein Föderationsproblem, wodurch der Inhalt in der Regel nur auf der Instanz des Erstellers sichtbar bleibt.
- Hinterlegung der Domains in Lemmy's Beleidigungsfilter
Dieser Filter wertet nur Textinhalte aus, Direktlinks aus Posts zu Archivlinks (URL Feld bei der Erstellung von Posts) können hiermit nicht gefiltert werden.
Für lokale Nutzer werden entsprechende Inhalte nicht mehr erstellbar sein bis die Domain entfernt wurde.
Inhalte von Nutzern anderer Instanzen werden bei der Föderation zensiert, indem die betroffenen Stellen im Text durch *removed* ersetzt werden. Der Inhalt wird nur bei uns geändert, andere Instanzen ohne diese Konfiguration zeigen den ursprünglichen Inhalt an.
- Entfernung von betroffenen Inhalten per AutoMod
Diese Option würde betroffene Inhalte im Modlog vermerken und würde uns auch die Möglichkeit geben weitere Logik anzubinden, wie eine PM an den betroffenen Nutzer zu senden, wenn der Inhalt in einer unserer Communities war. Für Communities von anderen Instanzen würden wir hier keine Benachrichtigungen einbauen.
Diese Maßnahmen würden sich nur auf neue Inhalte beziehen, wir haben aktuell nicht vor alte Posts und Kommentare zu entfernen o.ä.
Wir bitten hiermit um Kommentare mit euren Meinungen bis Sonntagnachmittag dazu, bevor wir auf Adminebene entscheiden wie wir letztendlich damit umgehen wollen. Primär wollen wir uns hier an Feedback von lokalen Nutzern orientieren, jedoch werden wir natürlich auch Kommentare von Nutzern anderer Instanzen berücksichtigen, da diese natürlich auch mit unseren Communities interagieren.
Zu archive[.]today gehören mindestens folgende Domains:
archive[.]todayarchive[.]isarchive[.]pharchive[.]foarchive[.]li
Hello everyone,
approximately 2 weeks ago someone reported a DDoS orchestrated by the operator of archive[.]today, also known from other domains like archive[.]ph or archive[.]is, on Hacker News.
The HN post itself is questionable, as you can see in the HN comments, especially concerning the poster's name, but the content is accurate.
The DDoS attack runs as JavaScript code in the browser of visitors of archive[.]today websites. Effectively this abuses the devices and abuses the devices of visitors for the attack. Effectively this abuses the devices of visitors for the cyberattack, which makes it a lot more challenging to block on the recipient's side. Someone knowingly participating in a botnet may also be guilty of Computer sabotage" according to § 303b StGB in Germany or similar laws.
This is currently still ongoing, as visiting the CAPTCHA sites still delivers JavaScript code for the DDoS, to access the targeted site many times. Most commonly used content and ad blockers like uBlock Origin should already be filtering this by default, but we can't expect everyone to use them, especially on mobile devices.
Originally, @eb@social.coop posted about the attack in this thread with additional details further down the thread. Specifically here and here.
A bit later there was another report by @iampytest1@infosec.exchange, who also reached out to the operator by email, asking for a statement. According to iam-py-test he received a response, which admits the attacks to be originating from archive[.]today. Based on this we can assume that this is not just a case of a compromised server.
As archive[.]today is a rather popular service for archival of websites we don't want to implement drastic measures against this without community feedback. In the last days we've considered which actions we could take and what their impacts will be:
- Adding the domains to Lemmy's URL filter
For local users, content linking to affected domains cannot be posted anymore until the link is removed.
Content from users on other instances will be dropped as it's received through federation and will never appear on our instance. For content in our communities users will also not be informed, for them it will look like just a federation issue, which will typically result in the content only being visible on the instance of the creator.
- Adding the domains to Lemmy's slur filter
This filter only evaluates text content, direct links from posts to archive urls (URL field when creating a post) cannot be filtered with this.
Local users won't be able to post affected content until the domain has been removed.
Content from users on other instances will be censured as it's being processed by federation by replacing affected sections in the text with *removed*. Content will only be changed on our instance, other instances without this configuration will still show the original content.
- Removal of affected content via AutoMod
This option would log affected content in modlog and would also allow us to implement additional logic, like sending a pm to users being moderated within one of our local communities. We would not notify users about content in communities on other instances.
These measures would only affect new content, we are not planning to remove or otherwise change old posts or comments.
Please comment your opinions on this until Sunday afternoon (CET), before we'll make the final decision on admin level on how we will deal with this. Primarily we want to base our decision on the feedback from local users, but we'll of course also consider comments from users on other instances, as they are also participating in our communities.
At least the following domains belong to archive[.]today:
archive[.]todayarchive[.]isarchive[.]pharchive[.]foarchive[.]li
@who@feddit.org : this is sadly not possible, as Anubis knows nothing about the user session or login status of the user within Lemmy (or cookies for that matter). It's a tool that does heuristic checks, taking into account e.g. the IP address, the browsers user-agent header etc. It however stores sessions it has "seen" for 12h (with its own cookie) and doesn't send a challenge as long as this is persisted.
If you're seeing the challenge multiple times a day, that this usually means that the cookie either was deleted, or the session somehow otherwise got interrupted on the client side.