Ehemaliger Gizmodo-Reporter änderte seinen Namen in „Slackbot“ und blieb monatelang unentdeckt

• Tom McKay von IT Brew tarnte beim Verlassen von Gizmodo im Jahr 2022 sein eigenes Slack-Konto als Slackbot und entging so monatelang der Löschung
• Slack blockierte zwar den bereits verwendeten Namen „Slackbot“, doch McKay umging die Beschränkung des Anzeigenamens mit ähnlich aussehenden Unicode-Zeichen
• Auch das Profilbild änderte er in eine wütende Version, die dem echten Slackbot-Symbol ähnelte, sodass Administratoren den doppelten Slackbot samt unterschiedlicher Augenbrauen nicht bemerkten
• Solange das Konto bestehen blieb, konnte McKay Kolleginnen und Kollegen botartig wirkende Nachrichten schicken, etwa „Slackbot fact of the day“
• Je nach Unternehmen kann es Sicherheitsmaßnahmen geben, die solche Streiche verhindern, weshalb das Bereinigen von Konten ausgeschiedener Mitarbeitender und die Prüfung von Anzeigenamen wichtig sind

---

Slack-Konto blieb nach dem Ausscheiden bestehen

• Tom McKay von IT Brew tarnte nach seinem Abschied von Gizmodo sein eigenes Slack-Konto als Slackbot
• McKay teilte auf X einen Screenshot aus der Zeit und bestätigte The Verge, dass dieser Streich echt war
• Das getarnte Konto wurde von der Gizmodo-Administration monatelang weder entdeckt noch gelöscht

So ließ er es wie Slackbot aussehen

• Slackbot ist ein vertrauter Bot in Slack, der bei Benachrichtigungen hilft, das Büro-WLAN-Passwort nachschlägt und auf Erwähnungen in Kanälen hinweist, denen man nicht beigetreten ist
• Beim Ausscheiden änderte McKay sein bisheriges Profilbild in ein wütendes Bild, das dem echten Slackbot-Symbol ähnelte
• Er versuchte auch, den Anzeigenamen in „Slackbot“ zu ändern, doch Slack erlaubte die normale Änderung nicht, weil der Name bereits verwendet wurde
• Stattdessen umging er die Namensbeschränkung mit Unicode-Zeichen, die Buchstaben ähnlich sehen
  • Beispiel: Er ersetzte das „o“ durch das ähnlich aussehende Unicode-Zeichen „о“

Was über Monate möglich war

• Durch diese Änderung entging McKays aktives Slack-Konto monatelang der Löschung
• Solange das Konto bestehen blieb, konnte er Kolleginnen und Kollegen Nachrichten schicken, die wie Bot-Nachrichten wirkten
  • Beispiel: „Slackbot fact of the day: Hi, I’m Slackbot! That’s a fact. Have a Slack-ly day!“
• Victoria Song, die früher bei Gizmodo gearbeitet hat, reagierte darauf, als sei die Situation nicht überraschend

Mögliche Schutzmaßnahmen je nach Unternehmen

• Nicht jedes Unternehmen fällt auf dieselbe Weise darauf herein; manche verfügen über Sicherheitsmaßnahmen, um solche Situationen zu verhindern
• Die Gizmodo-Administration könnte gedacht haben, dass McKays Konto bereits gelöscht worden war
• Oder sie sah nicht genau genug hin, um einen doppelten Slackbot mit verdächtigen Augenbrauen zu bemerken

[GN⁺]

Hacker-News-Kommentare

• Ein ehemaliger Mitarbeiter, den ich früher kannte, hatte einmal in einem Modem-Rack-Controller-Modul ein Dial-up/ISDN-Provisioning-Profil namens Ringing angelegt. Er mied den Radius-Server, weil es dort zu offensichtlich gewesen wäre.
  Auf der Statusseite des Modem-Racks sah man neben den verbundenen Nutzern einen Ringing-Status, als würde noch ein Anruf nicht angenommen, und er nutzte über ein Jahr lang völlig unentdeckt einen 128-Kbit-ISDN-Service.
  Natürlich empfehle ich so etwas nicht. Besonders heute, wo der CFAA teils so ausgelegt wird, dass er sogar das Ändern von URL-Parametern oder das Schnippen von Popeln auf den Teppich umfasst.

  • Ich frage mich, ob es Belege zum CFAA gibt. Eher wirkte es so, als sei das Ändern von URL-Parametern wahrscheinlich kein Problem.
    Nach dem Recht von New Jersey musste die Regierung für eine Verurteilung wegen „unbefugten Zugriffs oder Überschreitens der Zugriffsberechtigung“ nachweisen, dass eine code- oder passwortbasierte Barriere umgangen wurde; in dem Fall ging es im Kern nur darum, dass jemand auf Teile einer öffentlich zugänglichen Login-Seite zugriff und Informationen scrapte, die AT&T unbeabsichtigt öffentlich gemacht hatte.
    https://law.justia.com/cases/federal/appellate-courts/ca3/13...
  • Erinnert mich ein wenig daran, wie ich mich in Warcraft-II-LAN-Partien, wenn zwei Brüder im Koop gegen den Computer spielten, in Computer umbenannt und heimlich beigetreten bin.
  • Bei einem früheren Arbeitgeber habe ich einmal still mehrere Monate darauf gewartet, dass man meinen Account aus Slack entfernt. Selbst fast ein Jahr später hatte ich noch vollen Zugriff auf einen großen Teil der internen Channels, was wirklich merkwürdig war.
    Die Leute dort waren zwar befreundet mit mir, aber es war nicht aus Nettigkeit so gelassen worden, sondern weil die Slack-Account-Verwaltung und die Google-Office-Integration ein Chaos waren.
  • Keine Ahnung, was es mit CFAA und der Popel-Geschichte auf sich hat. Ich finde dazu auch per Suche keine Referenzen.

• Das erinnert mich an einen glorreichen Tag um 2016 bei einer Consulting-Firma, als wir herausfanden, dass wir gegenseitig unsere Slack-Namen ändern konnten. Eine Zeit lang hießen alle einfach dad.

  • Klingt ganz ähnlich wie damals, als Kinder merkten, dass jeder Namen und Bilder von Netflix-/Disney+-Profilen ändern kann.
  • Nett, aber ich bleibe bei grandad. Oder ich lasse meine Enkelinnen los; die sind gnadenlos.
  • Geht das immer noch?
    Das Ultimate-Frisbee-Team meiner Uni nutzt Slack.

• Viele empfehlen, Namensänderungen zu verhindern, aber damit ist das Problem nicht vollständig gelöst. Es könnte ja irgendwo auch jemanden geben, der tatsächlich Jira heißt.
  Bei $company, wo ich früher gearbeitet habe, lag das Kunden-Dashboard auf einer Wildcard-basierten Adresse https://*.$company.com, also etwa https://foo.$company.com.
  Wenn aber jemand einen Dashboard-Slug wählte, der mit einem echten Record wie www oder blog kollidierte, wurde dieses Dashboard komplett unerreichbar. Die Einstellung zum Ändern des Präfixes lag ebenfalls unter https://$dashboard.$company.com, sodass der Kunde es nicht selbst beheben konnte und der Support gebraucht wurde. Natürlich boten auch die Support-Tools keine Funktion an, um das $dashboard-Präfix direkt zu ändern.
  Auch wie man eine Blockliste erstellt, ist nicht trivial. Man braucht bestehende DNS-Einträge, bereits vorhandene $dashboard-Präfixe, Schimpfwörter, Unicode-Symbole, das Punycode-Präfix xn--, Redirects von früheren Präfixen und Reservierungen, um künftige Vorwegnahmen zu verhindern.
  Es überrascht mich nicht, dass Slack so eine Lücke hat. Im Kern ist das ein schwieriges Problem.

  • Zendesk legt Kunden-Dashboards als direkte Subdomains seiner Hauptdomain ab. Eigene Domains sind ebenfalls erlaubt; dafür muss man einen CNAME auf die von Zendesk vergebene Subdomain setzen.
    https://support.zendesk.com/hc/en-us/articles/4408838571930-...
    Ich denke, Subdomains für Kundenseiten sollten zumindest auf einer separaten Domain liegen, wie bei GitHub oder Shopify. GitHub nutzt GitHub.com als eigene Domain und GitHub.io als Domain für Nutzerseiten, und Shopify trennt ebenfalls Shopify.com und myshopify.com.
    Der Vorteil einer separaten Domain für Kunden ist, dass sie weniger mit bestehenden oder künftigen Subdomains kollidiert, die das Unternehmen selbst verwenden möchte, und dass man diese Domain in die Public Suffix List aufnehmen lassen kann, um potenzielle Probleme zu vermeiden. Beleidigende oder irreführende Wörter muss man trotzdem filtern.
    https://publicsuffix.org/
  • Am Arbeitsplatz meines Ehepartners gibt es tatsächlich einen Mitarbeiter namens Admin. Die IT hat große Schwierigkeiten, damit umzugehen.
  • Will hier wirklich jemand Slack verteidigen? o und о gehören zu den wohl einfachsten möglichen Homograph-Angriffen.
    https://en.wikipedia.org/wiki/IDN_homograph_attack
    Es geht darum, dass McKay beim Ausscheiden sein Profilbild in ein noch wütender wirkendes Slackbot-Icon geändert und seinen Namen in Slackbot geändert hat; Slack blockiert zwar den Namen Slackbot, weil er bereits verwendet wird, aber wenn man das o durch das Unicode-Zeichen о ersetzt, funktionierte es.
    Dieses englisch/kyrillische Zeichenpaar wurde bereits in einem der frühen, 2001 veröffentlichten Homoglyphen-Angriffe verwendet.
    https://web.archive.org/web/20200102175251/http://www.cs.tec...
    2022 war Slack ungefähr 20 Milliarden Dollar wert und seit fast zehn Jahren in Betrieb. Außerdem handelt es sich um nutzernamenbasierte Software, die sich an Organisationen und Unternehmen richtet, die Sicherheit brauchen.
  • Man kann die zulässigen Zeichen beschränken und vor dem Zulassen einer Änderung einfach prüfen, ob die betreffende Seite bereits aufgelöst wird. Dann werden Kunden nicht ausgesperrt, und es wird auch schwerer, sich über Zeichen als jemand anderes auszugeben.
    Wenn man bestimmte Symbole erlauben möchte, kann man eine Allowlist verwenden oder prüfen, ob der Nutzername eine ausreichende Levenshtein-Distanz zu Kernnamen wie slackbot hat, und ihn andernfalls verbieten oder zur menschlichen Prüfung markieren.
    Alles zu verhindern ist im Kern schwierig, aber die größten Probleme zu verhindern ist nicht schwer.
  • In diesem Fall ist „sorgt dafür, dass grundsätzlich unterschiedliche Namensräume nicht kollidieren“ kein besonders schwieriges Problem.

• Der beste Ort zum Verstecken ist, wie ein Service-Account auszusehen, den niemand anzufassen wagt, weil niemand weiß, was kaputtgeht, wenn man ihn deaktiviert. Gut gemacht.

  • Umgekehrt hat bei uns im Unternehmen einmal ein übereifriger IT-Mitarbeiter den Jira-Automatisierungsaccount gelöscht. Er wusste nicht, wozu der Account da war, und der Name $CompanySecretary wirkte verdächtig.
    Ein paar Tage später hatten wir große Mühe, alle Workflows und Tickets zu finden und zu reparieren, die auf diesen Nutzer verwiesen, bevor etwas wirklich Wichtiges kaputtging.
  • Das erinnert mich an bekannte Malware und deren Prozessnamen.

• „Natürlich fällt nicht jedes Unternehmen auf diesen Streich herein“, aber vielleicht lacht am Ende das Unternehmen: https://en.wikipedia.org/wiki/Computer_Fraud_and_Abuse_Act

  • Genau deshalb ist der Punkt, dass er zwei Jahre gewartet hat, bevor er darüber gesprochen hat. Das passt gerade zur Verjährungsfrist des CFAA.
  • Das war mein erster Gedanke, als ich die Formulierung „harmloser Streich“ gelesen habe.
  • Am Ende könnte auch Slack lachen. Schließlich bekommt man dadurch jede Menge „sensible Geschäftsdaten“ in die Hände.

• ASCII-Zeichen durch ähnlich aussehende Unicode-Zeichen zu ersetzen, ist ein alter Trick. Es gibt ziemlich viele solcher Zeichen, und man kann sie in Code einbauen, um andere Entwickler zu ärgern. Der 1. April ist auch nicht mehr weit
  Ich habe auch ein Vim-Plugin gebaut, das solche „gefährlichen“ Zeichen hervorhebt: https://github.com/vim-utils/vim-troll-stopper
  Mir ist zwar noch nie ein Streich mit Unicode-Zeichen gespielt worden, aber einmal hat ein japanischer Consultant unbeabsichtigt ein „japanisches Leerzeichen“ in eine Übersetzungsdatei eingefügt, wodurch die App kaputtging. Da ich das Vim-Plugin immer aktiviert hatte, habe ich die Ursache schnell erkannt

  • Viele Apps haben freundlicherweise angefangen, zwei Bindestriche durch einen schöner aussehenden langen Unicode-Gedankenstrich zu ersetzen, wodurch Kommandozeilen-Tools kaputtgehen
  • Daran erinnere ich mich: https://news.ycombinator.com/item?id=10438363
  • Auch versehentliche Schrottzeichen können weit kommen. Ich erinnere mich an einen medizinischen Bericht, in dem jemand ein hochgestelltes O wie ein Gradzeichen verwendet hatte
    Das wurde später in ein nicht hochgestelltes Zeichen umgewandelt, wodurch sich die Bedeutung ziemlich änderte. Noch unfreundlicher war, dass nach diesem Versuch eines Symbols auch noch das Wort degrees stand

• Wenn Slack das Sperren von Namensänderungen nicht erlaubt, wäre das für große Unternehmen wohl ein riesiges Sicherheitsloch
  Wenn man den Namen in den des CEO ändert und auch das Profilbild anpasst, ist die Chance extrem gering, dass jemand den Unterschied bemerkt, bevor es zu spät ist. Sich in Slackbot umzubenennen wirkt dagegen wie eine Kleinigkeit

  • Namensänderungen lassen sich sperren. Ich bin in einer Enterprise-Grid-Organisation, in der Anzeigename und Benutzername mit dem Mitarbeiterprofil synchronisiert werden
    SSO ist außerdem jedes Mal Pflicht, wenn man die Desktop-App startet; wenn man also ausscheidet, kommt man auf keinen Fall wieder rein. Konten werden auch sehr schnell deaktiviert, daher ist Mobile wahrscheinlich auch kein großes Problem
    Praktisch das Einzige, was man ohne Ticket ändern kann, sind das Foto und ein paar wenig wichtige Freitextfelder
  • Das geht in den Organisationseinstellungen. Dasselbe gilt für die SAML/SSO-Diskussion weiter unten. Wenn man den Namen ändern kann, deutet das eher darauf hin, dass es keine IT-Admins gibt oder sie nachlässig sind
  • Große Unternehmen nutzen SAML oder andere föderierte Authentifizierung, damit man sich ohne Unternehmens-Login nicht anmelden kann
  • Gleichzeitig ist die Möglichkeit zur Namensänderung wirklich ein großer Segen
    Wir missbrauchen sie, indem wir direkt im Anzeigenamen unsere Verfügbarkeit eintragen. Zum Beispiel mike-2/12~16vac., damit Kontaktpersonen die Antwortzeit abschätzen oder ein paar Tage vor einem geplanten Urlaub sehen können, ob sie einem noch Arbeit geben sollten
    Das eigentliche Status-Attribut scheint niemand anzusehen, und es ist besser, als im Kalender nachzuschauen
  • Ich vermute, das ist einer der Gründe, warum unser Unternehmen kürzlich in seinem Videokonferenzsystem die Möglichkeit entfernt hat, dass Leute ihren Namen ändern

• Wenn man sich die Screenshots ansieht, in denen Leute ihm antworten, ist klar, dass sie wussten, dass er nicht Slackbot ist, und ihn sogar Tom nennen. Das widerspricht also etwas der Überschrift. Er war ganz offensichtlich nicht „unentdeckt“
  In unserem Slack sind auch noch ehemalige Mitarbeiter. Sie schauen manchmal vorbei und sagen hallo, was schön ist. Wenn einer von ihnen eines Tages anfangen würde, sarkastisch Slackbot zu imitieren, würden wir vermutlich auch einfach darüber lachen

  • Gemeint ist hier, dass er „vom Management nicht entdeckt“ wurde. Das steht auch eindeutig im Artikel. Seine Freunde wussten, dass er da war, und haben mitgelacht
  • Bei uns war es ähnlich. Slack war zwar nicht der wichtigste Kommunikationskanal, wurde aber für externe Consultants genutzt, und ausgeschiedene Leute blieben drin und verabredeten sich weiter zum Mittagessen

• An einem früheren Arbeitsplatz ging das Deaktivieren von Slack-Konten langsam. Deshalb habe ich beim Ausscheiden einen privaten Channel namens #daves_cave erstellt und Freunde eingeladen
  Ich habe dort gelegentlich kurze Geschichten oder witzige Sprüche hinterlassen, und es war lustig, bis das Management es bemerkte und mein Konto deaktivierte

  • Ich habe ein persönliches kostenpflichtiges Slack-Team, das, glaube ich, etwa 10 Dollar im Monat kostete. Man kann Leute aus anderen kostenpflichtigen Slack-Teams in Räume einladen und dort chatten
    Das Gute daran ist, dass es „by design“ vorgesehen ist, also wahrscheinlich nicht geschlossen wird und vermutlich auch weniger wahrscheinlich unter Gesetze zu Computermissbrauch fällt

• Ich vermute, das Unternehmen hätte gedacht, die Antwort auf dieses Problem sei Single Sign-On
  Heutzutage betreibe ich keine IT mehr, aber als ich das früher getan habe, haben wir ausgeschiedene Mitarbeiter in Azure Active Directory als inaktiv markiert. Dann konnten sie sich bei keinem Dienst wie Office 365, Outlook, Teams usw. mehr anmelden und auch nicht bei Drittanbieterdiensten, die MS SSO nutzen. Sollte Slack nicht auch daran angebunden werden?

  • Eine kompetente oder ausreichend besetzte IT-Abteilung würde das natürlich so machen. Es kann aber auch sein, dass eine andere Abteilung Slack eingerichtet hat, ohne die IT zu konsultieren