LNP309 Bin ich schon raus oder was?

Feedback — Kasachstan — Advanced Persistent Threats - SIM-Swapping — Facebook — Huawei — Sytech — Termine

Wir haben es mal wieder geschafft, eine Sendung ins Sommerprogramm zu schmuggeln und grasen ein wenig die weitgehend dünne Nachrichtenlage ab. Diesmal wieder einigem Erklärbär-Potential und ein paar Lacher haben wir auch noch untergebracht. Also: ein perfektes Logbuch!

Dauer: 1:22:49

On Air
avatar Linus Neumann Paypal Icon Bitcoin Icon Amazon Wishlist Icon
avatar Tim Pritlove Paypal Icon Bitcoin Icon Liberapay Icon Amazon Wishlist Icon

Feedback: Die H&M-Konfusion

Kasachstan in the middle

Advanced Persistent Threads

Österreich: SIM-swapping zur Strafverfolgung?

Facebook-Strafe

Huawei-Boykott

Sytech-Hack

Termine

13. September 2019: Logbuch:Netzpolitik bei “Das ist Netzpolitik!”

38 Gedanken zu „LNP309 Bin ich schon raus oder was?

  1. Ich glaube, dass Linus zu optimistisch ist, was die Möglichkeit angeht Code signing etc. für Office Makros auszurollen.

    Sicher: Technisch gibt es da Lösungen, aber aus der Praxis von Unternehmen, die ich kenne aus dem nicht-technischen Bereich fängt ein großer Teil der Excel-Macros ja damit an, dass man in der Fachabteilung eine Kleinigkeit will und nicht mit der IT-Abteilung interagieren will, da die so viele Fragen stellen und es so lange dauert. Statt dessen geht man zum Sohn eines Kollegen aus der Abteilung, der sich “ganz toll auskennt” und der erstellt dann Makros auf einem System außerhalb der Zertifikatshoheit des Unternehmens und das ist so toll, dass das doch alle in der Abteilung nutzen und sich so daran gewöhnen jeden noch so umständlichen Hinweis weg zu klicken.

    Dazu kommt noch, dass solche Dinge oftmals zwischen Organisationen/Firmen hin und her geschickt werden (“Ja, sowas können wir wohl machen, trag dich Mal deine Daten in das Makro ein, dann gibt es einen Entwurf”) und es da keine zentrale Zertifizierungsstelle mehr gibt.

    Und dann die Frage, wie viele Unternehmen überhaupt eine brauchbare IT-Abteilung haben, die sowas abfangen könnte.

    Jetzt könnte man hingehen und Makros (wie auch immer, keine Ahnung ob es da Systempolicies gibt oder Microsoft erst Mal drehen müsste) komplett abschalten.

    Was ist die Folge? (Erstmal, dass Microsoft die Position verliert – Excel runs the world. Wenn MS Makros einfach abschaltbar macht gibt es kaum noch einen Grund deren Software einzusetzen – aber ignorieren wir das) Die Folge ist, dass dies Tool in eine PHP (oder modern Node.js?) Skripterei auf irgendeinem Server läuft. Mit Glück läuft dies dann auf einem öffentlichen Server, dann bekommt der Angreifer zwar die Daten des Tools (Kundendaten?Abbildung interner Prozesse?) aber keinen direkten Sprung ins Firmennetz … aber die User sind identifizierbar, so dass ein gezielter Angriff über den Browser gefahren werden könnte …

    Ein weiterer denkbaren Ansatz wäre strikteres Sandboxing: So lange das Makro nur mit Daten im Dokument hantiert ist es weitestgehend fein. Für alles weitere braucht es dann weitergehende Erlaubnis. Mit Ja aScript I’m Browser haben wir ja inzwischen ein halbwegs funktionierendes Sandboxmodell. Probl: Legacy. Alles in Office geht über COM und wenn man da einmal drin ist …

    Ja, wäre schön, aber realistisch? – Sehe ich nicht. Nimmst Du Fachabteilungen ihr Excel und Macros weg, erntest Du kein Verständnis sondern massiven Protest und “kreative” Lösungen (“dann bringe ich halt den privaten Laptop mit und stecke da das Netzwerkkabel rein”)

    • Sehe ich ähnlich. Am Ende gingen Linus’ Bemerkungen ja in diese Richtung.

      Solange Excel-Files mit Makros per unsignierter Email durch die Gegend geschickt und vom Empfänger geöffnet werden, müssen wir über Code-Signing nicht reden.
      Ist wie beim Firefox-Thema: im Zweifel wird auch die Warnung weggeklickt.

      Dein Sandboxing-Ansatz ist zwar ganz nett; leider werden Makros gerne auch mal dazu eingesetzt, Daten aus anderen Excel-Files zu laden.

      • Darum stellt der verantwortungsvolle Admin auch die Option ein, dass Makros aus nicht vertrauenswürdiger Quelle (Email z. B.) deaktiviert. Findige User merken dann bald, dass Copy/Paste den Schutz umgeht. Aber den Doppelklick-Dau kann man so einfangen! :-)

  2. https://support.office.com/en-us/article/Electronic-signatures-A0B14746-DA5D-4743-A909-7E9BE5911196#__toc262112911

    Seit *Office 2007* kann man Office-Dokumente digital signieren. Seit *Office 2010* kann ein Admin per group policy festsetzen, wie Makros in Dokumenten behandelt werden. https://gpsearch.azurewebsites.net/#6198 Mögliche Settings sind Never warn, disable all. und Warning for signed, disable unsigned. D.h. auch den Warning bar ausblenden und *immer* disablen.

    Ich will ja jetzt nicht victim bashing betreiben, aber leider besteht da ein Awareness bzw. Schulungsproblem und oft sieht man auch ein Executive Override der Form: Aber dann geht mein Business Intelligence/Datenbankabfrage/Formtextgenerator/Lieblings-Makro-Hack etc. nicht mehr. Und der Admin, der der Vertriebsabteilung den Vertriebs-Bonus-Plan-Rechner zerstört, der ist nicht mehr lange Admin.

    *seufz*
    H.

    • Die Betonung liegt auf KANN.
      Das Ergebnis ist, dass es NIRGENDWO angewendet wird.
      Solche Dinge müssen leider erzwunden werden, indem sie zum Standard gemacht werden.
      Siehe App Store & „vertrauenswürdige Quellen“

    • das Office Thema scheint die Geschäftswelt ja zu verfolgen und daher auch hier wieder aufzutauchen.

      Das Problem mit dem aktuellen Warnschild-Dialog ist, dass es keinen Lesemodus gibt, der grundlegende Funktionen mitbringt.
      Wenn ich, wie im Gespräch empfohlen, auf das kleine “x” rechts im gelben Warndialog drücke, dann sind auch folgende Funktionen dekativiert:
      * Drucken (auch PDF)
      * Speichern
      * Zeiger in Zellen setzen (F2 in Excel)

      Diese Funktionen würden den meisten Nutzern in den meisten Fällen ja ausreichen.

      • Unsere Shownotes sind immer ein guter Anfang ;) Dass du auch Ergebnisse zum gleichbedeutenden Begriff findest, liegt daran dass sie synonym sind.

        In der Tat setzt sich die geschlechterneutrale Formulierung in der Tech-Community schon seit mehreren Jahren immer mehr durch.

  3. Hallo Linus & Tim,

    Ich würde gerne wissen wo ihr das mit machine-in-the-middle her habt.
    Ich hab versucht das nach zu googlen, fand aber nur Ergebnisse die es man-in-the-middle nannten.

    Muss ich jetzt vielleicht sogar differenzieren zwischen machine-in-the-middle und man-in-the-middle?

    • Unsere Shownotes sind immer ein guter Anfang ;) Dass du auch Ergebnisse zum gleichbedeutenden Begriff findest, liegt daran dass sie synonym sind.

      In der Tat setzt sich die geschlechterneutrale Formulierung in der Tech-Community schon seit mehreren Jahren immer mehr durch.

  4. Ihr erwähnt kurz am Rande 2FA und OTP. Habt ihr ggf. Empfehlungen für passende (iOS) Apps?
    Google Authenticator und FreeOTP sind, was UI und UX belangt, wirklich schrecklich. Keine Möglichkeit für Backups/Export, keine Suche, kein Tagging, eigene Sortierung oder sonstiges.

    Datenschutzfreundliche Alternativen mit o.g. Funktionalität sind mir leider noch nicht untergekommen. Von Authy hat es mir genügt, die Datensamme^W Daten”schutz”erklärung zu beginnen zu lesen…
    Am besten wäre natürlich noch, wenn die App keinen Subscription Zwang hat.

    Ansonsten Danke für die Sendung. Im Zusammenhand mit Authentifizierung über die Mobilnummer und Abschnitt davon bei Kündigung, hättet ihr super einen Hinweis auf “freenet Funk” einbringen können, die ja ihren Kunden, die das Produkt auch nutzen, einfach kündigen. https://www.teltarif.de/freenet-funk-vielnutzer-kuendigung/news/77374.html

    • Fehlende eigene Sortierung stelle ich gerade fest, stimmt nicht. Bieten beide genannten Apps. Ändert aber nichts an der grundsätzlichen Kritik der Benutzbarkeit.

  5. Hi,
    danke für die Hinweise aus die CRE-Folgen zu GSM.
    @Tim
    Leider sind in Overcast und anderen Apps nur die Folgen ab 160 verfügbar. Lässt sich das ändern? Danke

  6. Moin,

    da dies mein erster Kommentar ist erstmal danke für den Podcast, er hat mir schon viele lange Stunden in der Bahn und dem Auto versüßt.

    Nun zum Feedback bzgl. MitM:
    Die Darstellung, welche ja in CCC Kreisen immer wieder geteilt wird, dass TLS-Interception eine „Unart“ wäre die in Unternehmen nur dazu benutzt wird Mitarbeiter auszuspähen und den ungewollten Transfer von Geschäftsgeheimnissen abzuwehren halte ich für vollkommen falsch.

    Als Pentester und Red-Teamer kann ich euch sagen das eigentlich alle größeren Infrastrukturen die ich kenne TLS-Interception dazu einsetzen IOCs (Indicators Off Compromise) im ausgehenden Traffic überhaupt detektieren und so einen Angreifer beim „nach hause telefonieren“ entdecken zu können.
    Natürlich ist das bei weitem nicht der einzige Weg für das Blue-Team einen Angreifer zu ertappen, ist jedoch ein integraler Bestandteil einer sog. Defense-in-Depth-Strategie bei der es darum geht an möglichst vielen Stellen Hürden für den Angreifer aufzubauen die er zu überspringen hat. Im Falle von TLS-Interception würde man ihn beispielsweise dazu zwingen seinen Command-and-Controll traffic zu obfuskieren – unterlässt er dies könnte es in einer schnellen Entdeckung auf Basis simpler Traffic-Pattern münden. Ohne die entsprechende Technologie sind sowohl manuelle als auch automatische Untersuchungen unmöglich.
    Dies gilt insbesondere dann, wenn der Traffic z.B. durch Domain-Fronting zu eigentlich vertrauenswürdigen zielen geleitet und hier dann umgelenkt wird. Hier wäre dann noch nicht mal mehr auf Basis von „ungewöhnlichem“ Traffic eine Anomalie festzustellen.

    Auch das oft angeführte Argument das TLS-Interception downgrades durchführen würde ist nur dann haltbar, wenn man den falschen Anbieter für das intercepten des Traffics wählt da es durchaus Lösungen gibt die auch mit aktuellsten Cipher-Suites arbeiten können.

    Letztlich sollte jetzt also besser niemand losrennen und WENIGER TLS-Interception in Unternehmen fordern. Im Gegenteil sollte es eher MEHR werden um eine Entdeckung von Angriffen am Perimeter überhaupt zu ermöglichen. Die Privatsphäre von Mitarbeitern kann durch Ausnahmen bei der Interception z.B. bei Webmail für das private lesen/versenden von Mails trotzdem gewahrt werden.

    Beste Grüße
    flux

    • Der Ansatz “TLS-Interception” ist leider weitestgehend sinnlos, weil er darauf angewiesen ist, dass der Angreifer hinreichend inkompetent ist, noch nie etwas von Steganographie gehört zu haben. Und es geht natürich auch noch einfacher: Dank der überbordenden (und z.T. erzwungenen) Telemetrie in den meisten Softwareprodukten, die oft genug ihre Daten an irgendwelche häufig wechselnden Azure-, AWS- oder GCP-Instanzen schickt, wird eine zusätzliche Azure- oder AWS-Instanz eines Angreifers kaum auffallen.

      Hinzu kommt, dass die Appliances, die für TLS-Interception üblicherweise benutzt werden. seit Jahren immer wieder durch haarsträubende Sicherheitslücken auffallen – und je mehr Protokolle und Dateiformate so eine Appliance analysieren kann, desto größer ist natürlich auch die Angriffsfläche, die die Appliance selber bietet. Und so eine Appliance zu kompromittieren ist der Jackpot für jeden Angreifer: Die Appliance steht i.d.R. an einer privilegierten Position in der Netzwerktopologie, im Zweifelsfall hat der Eigentümer gar keine praktikable Möglichkeit, nachzuprüfen, ob die Appliance eventuell kompromittiert wurde, oder bei Verdacht die Appliance zuverlässig zurückzusetzen in einen “known-good”-Zustand. Dass man als Angreifer dazu dann auch noch ne CA kriegt, die nicht Certificate Transparency unterliegt, der jeder Rechner im anzugreifenden Unternehmen vertraut, und bei deren Zertifikaten die Browser üblicherweise sogar Certificate Pinning ignorieren, ist natürlich ne besonders leckere Kirsche auf dem Kuchen.

      Der bessere Ansatz ist, Systeme so einzurichten, dass

      1. Sicherheitsupdates nach Erscheinen immer zeitnah eingespielt werden,

      2. normale User möglichst gar keinen Schadcode ausführen können (unter Windows wäre ein Tool dafür z.B. “AppLocker” – verfügbar in den Enterprise- und Server-Versionen ab Windows 7 bzw. Server 2008R2), und natürlich generell Zugriffsrechte auf das notwendige Minimum beschränkt werden,

      3. Netze und Systeme so konfiguriert werden, dass sie möglichst nicht auf die Vertrauenswürdigkeit irgendwelcher Netzwerksegmente angewiesen sind (natürlich sollte man Netze segmentieren um Angreifern das Leben möglichst schwer zu machen, aber man sollte sich nicht darauf verlassen, dass es schon kein Angreifer in das “sichere” firmeninterne Netz schaffen wird),

      4. Nutzer regelmäßig geschult werden. Z.B. einfach mal einführen, dass 1% der User nach dem Zufallsprinzip 1x die Woche ne gut gemachte Spearphishing-Mail kriegt – wer die Mail erkennt und meldet, kriegt nen Hunni, und wer auf die Mail reinfällt, kriegt kein Shaming sondern halt noch intensivere Schulung.

      Der nächste Schritt wäre dann, alles so auszulegen, dass möglichst alle Systeme austauschbar sind, und genau das dann auch regelmäßig bei allen Systemen, bei denen es möglich ist, durchzuführen, d.h. das System (möglichst automatisiert) neu aufzusetzen. Systeme, bei denen das nicht möglich ist, sollten entsprechend nochmal zusätzlich in eigene abgeschottete Netzwerksegmente gesperrt werden.

      • Ein paar Punkte müsste ich hier nochmal ansprechen:

        Selbst wenn die Inhalte im HTTPS-Datenstrom nochmals obfuskiert oder verschlüsselt wurde ist für einen automatisierten oder menschlichen Analysten recht schnell klar, dass hier etwas nicht stimmen kann da Traffic innerhalb von TLS-Kanälen nur selten verschlüsselt wird (kommt vor, ist aber selten der Fall z.B. bei manchen Banking-Apps) und die obfukation selbst garantiert auch nicht wie üblicher traffic aussieht. Steganographie ist auf jeden Fall interessant aber eher für die exfiltration von Dateien geeignet, nicht für C2.

        Im Zusammenspiel mit anderen Auffälligkeiten kann hier also durch ein gutes Monitoring und die entsprechenden Menschen schon mal ein Incident generiert werden dem man dann nachgeht.
        Ein solcher Ansatz bietet zumindest die Möglichkeit einen C2 zu entdecken auch wenn der Traffic zu den üblichen AWS etc. Providern geht. Natürlich ist aber nichts sicher. Es ist eben nur ein Teil der Gesamtstrategie.

        Angreifer nutzen im Übrigen oft genug Standardsoftware wie die von euch angesprochen Winti Backdoor. Hier hat man tatsächlich nicht allzu schlechte Chancen sie auch zu erwischen. Wie du eben sinngemäß in der letzten Sendung sagtest: „Die Angreifer Kochen am Ende auch nur mit Wasser“.
        Die Chance das einem da einer ins Netz geht weil „Stangenmalware“ zum Einsatz kommt ist nicht gering und wird durch Traffic-Inspektion signifikant erhöht.

        Bezüglich der zusätzlichen Risiken die durch ein solches System entstehen hast du natürlich recht, aber letztlich hast du dieses Problem sobald du im Konzern eine CA aufsetzt und diese in allen Rechnern installierst. Sicherst du die CA nicht vernünftig ab war es das.

        Certificate Pinning ist soweit ich weiß in Browsern tot und fällt wieder raus. Transparency ist für Angreifer eine großartige Informationsquelle für vorhandene Applikationen, Webservices etc. da die Namen ja absichtlich der Öffentlichkeit zugänglich gemacht werden. Es ist als solches also auch diskutabel, wenn natürlich auch ein sinnvoller Ansatz.

        Zu deinen 5 Punkten:
        Sie sind alle korrekt und ebenso wie TLS-Interception Teil einer Gesamtstrategie. Jeder einzelne ist an und für sich aber nur eine weitere Hürde die ohne weiteres überwunden werden kann. So nutzen nicht mal ¼ aller APT Gruppen überhaupt Softwareschwachstellen sondern die üblichen Living-of-the-Land Mehtoden – sprich Windows Boardmittel wie Macros, Powershell, WMI, Windows-APIs, etc. Mit Patchen kommst man da also nicht weit.

        Selbiges gilt für Applocker das zwar eine Super-Sache ist, für das ich dir aber 50 Bypasses nennen kann von denen immer einer funktioniert.

        Netzwerk-Sep. ist gut, in einem Active-Directory Netz – und das sind nun mal die meisten – kannst du die wichtigen Ports aber nicht sperren. Wichtig ist hier schon der Ansatz des „Assumed Breach“ also davon auszugehen das der Angreifer ins Netz kommt – was wiederum der Grund ist warum man seinen C2 Traffic detektieren will.

        usw. usw….

        Wie gesagt: Am Ende müssen dem Eindringling so viele Dinge entgegen geworfen werden bis ihn eins an der Rübe trifft. Aus meiner Sicht gehört hier auch die TLS-Interception dazu

        • Steganographie ist trivial, funktioniert auch ohne TLS/HTTPS, und lässt sich problemlos so gestalten, dass sie automatisierten Tools nicht mehr auffallen wird – außer wenn das Tool so konfiguriert ist, dass es die IT-Abteilung den ganzen Tag mit False Positives zuschüttet, sodass eh nimmt mehr die Meldungen des Tools ernst nimmt.

          Deine Appliance triggert auf “übertragenes Datenvolumen”? Dann teile ich die Übertragung halt auf mehrere C2-Server auf, gerne auch bei unterschiedlichen Hostern oder in unterschiedlichen geographischen Regionen, und packe ggf. noch Kompression obendrauf.

          Deine Appliance triggert auf “unbekannte oder obskure Dateiformate”? Dann übertrage ich die Informationen halt als XML, JSON oder schlicht als PNG (z.B. als QR-Code oder schlicht die Payload als Farbwerte der Pixel).

          Deine Appliance versucht, PNG auszuwerten, und Steganographie (oder gar QR-Codes) im PNG zu erkennen? Sehr schön für mich als Angreifer, denn in libpng gibt es alle 6-12 Monate ne neue Sicherheitslücke, mit der man deine Appliance angreifen kann. Bonus: Weil diese Appliances alle keinerlei Sicherheitsmaßnahmen wie “ASLR” oder “Stack Protector” verwenden, kann man auch Lücken angreifen, die auf “normalen” Rechnern nicht so einfach ausnutzbar wären. Und wenn ich nicht auf die nächste Lücke in libpng warten will (oder die letzte Lücke wider Erwarten schon in der Firmware gepatcht wurde, und diese Firmware wider Erwarten vom Admin auch schon eingespielt wurde), wende ich mich eben einfach anderen, ähnlich ergiebigen Zielen wie z.B. “unzip”, “JSON-Parser” oder “XML-Parser” zu. Wie, deine Appliance analysiert diese Datenströme alle nicht, um weniger Angriffsfläche zu bieten? Tja, dann kann ich jetzt ja endlich in Ruhe meinen C2-Traffic durchleiten…

          Damit wir uns richtig verstehen: Netzwerkmonitoring ist durchaus sinnvoll, aber es soll sich auf OSI-Layer 2-4 beschränken – alles darüber bringt überproportional mehr Angriffsfläche als potenziell zur Angriffsabwehr nützliche Informationen mit sich. Den Aufwand für TLS-MITM steckt man im Zweifelsfall besser in die Härtung der Konfiguration der zu schützenden Rechnern. Konkret z.B.:

          – nur die minimal nötigen Zugriffsrechte für alle Accounts,

          – getrennte Accounts für Admin- und Nicht-Admin-Aufgaben,

          – wo immer möglich, Telemetrie abschalten,

          – für Autoupdater möglichst firmeneigene Update-Mirror betreiben,

          – Generell dafür sorgen, dass die Baseline an Traffic, die der einzelne Rechner “von sich aus” so produziert, 1. möglichst niedrig ist und 2. möglichst vollständig zu “wohldefinierten” firmeneigenen Servern geht. Dadurch wird es leichter, ungewöhnliche Traffic-Muster zu erkennen, und zwar ganz ohne dass dafür irgendwelche halbseidenen Appliances mit “enterprise-grade” (d.h. seit mindestens 3 Jahren veralteter) Software in den OSI-Layern 5-7 rumstochern müssen.

          Im nächsten Schritt kann man dann die Zugriffslogs dieser firmeneigenen Updateserver umso feinkörniger automatisiert auswerten, um frühzeitig zu erkennen, wenn jemand versucht, die Server aus dem Firmennetz anzugreifen.

          Netzwerksegmentierung in AD-Netzen: Doch, natürlich geht so was – aber das ist natürlich Arbeit, und erfordert im Zweifelsfall auch mehr Hardware und fachkundigeres (=teureres) Personal als ein vermeintlich einfacheres, unsichereres Setup.

          • Es ist – wie so oft – eben ein Dilemma. Fakt ist, dass ohne TLS-Interception selbst out-of-the-box Metasploit Traffic einfach so rausrutschen wird. Es ist ja letztlich die Gewissheit das TLS im Zweifelsfall aufgemacht wird die APT Gruppen zu solchen Handständen treibt in denen Sie dann mit E-Mails Befehle triggern.
            Müssten Sie nicht befürchten auf dem Weg durch den Perimeter geschnappt zu werden würden Sie ganz entspannt ihre Malware über Vector XY aufbringen, jede Stunde mal den C2 Server wechseln und tüchtig Jitter einbauen um nicht anhand von Peaks zu einem Ziel und sonstigen Korrelationen aufzufallen.

            Das angesprochene Problem des Traffic-Parsings ist natürlich völlig korrekt und mir auch nicht neu, die Konsequenz aus den genannten Gründen aber vollständig blind zu sein halte ich für zu krass.

            Wie gesagt ist Traffic Analyse (wie auch immer sie am Ende aussieht) natürlich nicht das Allheilmittel und nur ein kleiner Teil der von mir hier des Öfteren erwähnten Gesamtstrategie zu der auch die von dir genannten Punkte gehören.

            Netzwerksegmentierung in AD-Netzen: Vielleicht habe ich mich da unklar ausgedrückt. Natürlich kannst du eine Menge zumachen, für die Windows Anmeldung essentielle Ports aber nicht und diese reichen für lateral-movement mit administrativen Rechten oder den nächsten fancy MS17-010 Style Exploit, allemal. Ab dem ersten kompromittierten Server oder Admin ists eh vorbei da dann die volle Breitseite von WMI, WinRM & Co zur Verfügung steht. Ohnehin ist es ja die Frage ob der Angreifer überhaupt anstrebt sich großartig durch das Netz zu bewegen und dabei noch in irgendein Alerting zu rennen. Meist werden bei Spear-Phishing ja schon die Zielgruppen adressiert an die man heran will (Finance, Vorstand, etc.).

            Auch das Thema Separation ist aber nur einer der zahlreichen Bausteine der Strategie von denen ich mit dem TLS-Interception Thema ja nur einen einzigen angesprochen habe.

    • Die Privatsphäre von Mitarbeitern kann durch Ausnahmen bei der Interception z.B. bei Webmail für das private lesen/versenden von Mails trotzdem gewahrt werden.

      Genau deshalb macht man dann darüber sein Command&Control, wie zum Beispiel beim letzten Angriff auf die Bundesregierung ;)
      https://www.zeit.de/digital/datenschutz/2018-03/hackerangriff-bundesregierung-outlook-auswaertiges-amt

      Ich verstehe den Ansatz und habe ihn imho auch in vorherigen Folgen ausreichend gewürdigt.
      Ich weiss aber auch aus Erfahrung dass ein mittel begabter Teenager knapp 20min braucht um sein C2 so zu obfuscaten, dass jeder Web-Proxy das gemütlich durchlässt.

      Also steht doch am Ende die Frage, wie viel Angriffe das wirklich verhindern oder abmildern soll, und da sehe ich wenig bang for the buck.

      • Bzgl. Bundestag:
        Nach allem was ich weiß – das sind keine Insider Infos – wurde hier Malware über Macros in den Outlook Process injected und diese wiederrum durch den Inhalt von E-Mails die man an die entsprechende Outlook Instanz sendete von außen getriggert. Resultat war ein üblicher C2 Kanal über http(s). Outlook war hier also der „Schalter“, so wie man hier auch DNS und einen gesetzten TXT Record verwenden könnte, der Regelmäßig abgefragt wird und der letztlich nur „ON/OFF“ sagt.

        Mit den von mir angesprochen Ausnahmen für private Mitarbeiter-Kommunikation hat das nichts zu tun da die sich eher auf gmx, web, whatever bezog. Natürlich könnte auch dies als Kanal genutzt werden, aber erneut müsste der Angreifer hier erst mal herausfinden, dass es diese Ausnahmen gibt. Erneut erhöht man also seinen Aufwand.

        • Der Vollsätndigkeit halber eine Korrektur meiner selbst :-)

          Es geht natürlich um das Auswärtige Amt und nicht den Bundestag. Auch habe ich den Angriffe nicht korrekt dargestellt. AFAIK wurde hier eine malitiöse Outlook Regel per Macro installiert und diese dann per E-Mail getriggert. Diese wiederrum injizierte dann code in den Outlook Prozess welcher wiederrum den C2 aufbaute.

        • Natürlich könnte auch dies als Kanal genutzt werden, aber erneut müsste der Angreifer hier erst mal herausfinden, dass es diese Ausnahmen gibt.

          Das wäre eine Zeile libressl/libcurl.
          Übrigens macht man eher einen request zu einer Pornoseite, um zu sehen ob der DNS ehrlich ist und dabei weniger aufzufallen.

          • Muss eine Malware erst nach einem ungestörten Weg nach draußen suchen, sprich z.B. URL Kategorien wie Finance, Webmail u.ä. abklappern hat man eigentlich schon alles erreicht was man will: Der Angreifer macht Lärm und das gibt dem Monitoring die Chance ihn zu detektieren. Es ist nicht unüblich schon den Versuch solcher „Durchklingellei“ oder den Versuch auf allen 65k Ports nach außen zu kommen zu flagen. Mehr als eine weitere Hürde ist es nicht, dass hatte ich ja deutlich gemacht.

            Den Teil mit der Pornoseite und dem DNS verstehe ich nicht :-)
            Was ich meinte ist der übliche weg Malware per DNS zb alle 4-12h nach einem Record Fragen zu lassen und es über das Setzen des selbigen zu aktivieren. Kann, muss aber nicht, ein TXT record sein, geht natürlich auch mit A.

  7. Zur digitalen Infrastrukturen und Netzabdeckung in Kasachstan hättet ihr mal den Podcast “Auf Distanz goes Baikonur” hören sollen.

  8. Hallo Linus, hallo Tim,

    danke für die, wie immer, aufschlussreiche Folge!

    In Bezug auf die MITM-“Attacken” geht Linus freundlicher Weise auf die Deep Packet Inspection in Unternehmen ein, erläutert deren Nutzung zur Verhinderung von Leaks und bezeichnet diese dann als “Unart”. Zumindest habe ich das so verstanden… :)

    Zufälliger Weise arbeite ich in einem Unternehmen, das hochsensible (Kunden-)Daten verarbeitet. Vor einiger Zeit kam auch auf uns die Anforderung zu, das Risiko von Leaks durch Mitarbeiter zu vermindern. Die gesamte IT-Security hat hin und her überlegt und sich zum Schluss dazu durchgerungen, Data-Leakage u.A. durch eine Deep Packet Inspection zu betreiben. Sprich, auffällige Mails, Web-Uploads, etc. werden durch ein System herausgefiltert.

    Das Ergebnis war wiederum spannend: Trotz umfangreicher Awareness-Maßnahmen gibt es einen kleinen Teil von Mitarbeitenden, die offenbar unbelehrbar sind und sich sensibelste Daten an private E-Mail Adressen geschickt haben. Darüber hinaus gibt es immer wieder Consultants, die versuchen, geschäftskritische Daten aus dem Unternehmen zu schleusen.

    Das klassische Sperren von USB Ports oder ein Whitelisting von Websites helfen gegen diese Form von Innentätern nur bedingt, da besagte Nutzer i.d.R. Rechte missbraucht haben, die sie für die tägliche Arbeit zwingend benötigen, weil ein effektives Arbeiten sonst schlicht unmöglich wäre. Kurz: Die Vorfälle lagen nach meiner Einschätzung nicht an fehlenden weiteren Schutzmaßnahmen und wären ohne Deep Packet Inspection niemals aufgefallen.

    Dass Deep Packet Inspection eine Operation am offenen Herzen ist – und man daher sein OP Besteck sehr kennen muss – ist allen beteiligten klar. Die dabei entstehenden Risiken sind bekannt und wurden bewusst geringer gewichtet als ein potentielles Leak. Die Überwachung der Mitarbeitenden ist ebenfalls nicht gewünscht und wurde über eine Betriebsvereinbarung ausgeschlossen. Für Menschen, die während der Pausenzeiten privat surfen möchten, ist ein Gast-WLAN für private Geräte eingerichtet.

    Da Linus in einer vergangenen Folge bereits erwähnt hat, dass Deep Packet Inspection aus seiner Sicht in Einzelfällen (schlimmstenfalls) gerechtfertigt ist, wäre meine Frage: War der Begriff “Unart” in diesem Fall eine ggf. zu weit gefasste Verallgemeinerung? Oder gibt es Maßnahmen gegen Leaks, die weniger starke eingriffe Erfordern und in einer Organisation mit mehreren tausend Mitarbeitenden ähnliche Erfolge versprechen?

    • Meine Meinung zu DPI habe ich oben ja kundgetan – wenn auch eher aus anderen Gründen wie die die du aus deinem Unternehmen kennst.
      Wegen deiner Frage zu anderen Maßnahmen:
      Was mir im Bezug auf DLP immer recht sinnvoll vorkam ist dateibasierte Verschlüsselung auf Basis von Agenten auf den End-Points. Für die Mitarbeiter ist dies – bei entsprechend simplem Regelwerk – erstmal transparent, wird eine Datei aber nach außen gesendet kann man sie ohne das entsprechende Schlüsselmaterial abseits des Unternehmens-Clients nicht öffnen.
      Schwiewrig wirds natürlich wenn ein gewünschter Austausch mit externen Entitäten erfolgen soll, hier muss dann die verschlüsselung entsprechend (automatisiert) z.B. am E-Mail Gateway entfernt werden.

      Und jaja, wenn es jemand drauf anlegt und den Screen abknippst, oder ein Angreifer im SYSTEM Kontext Zugriff auf ein Endsystem hat ist es natürlich vorbei mit der Verschlüsselung.

  9. Ich habe sie Kommentare jetzt nur nach Korea durchsucht, Ohne die Diskussion gelesen zu haben, möchte jedoch zu dem Mobilfunknetz etwas beitragen.

    Seit ich vor zwei Jahren in Süd Korea war, verfolge ich die Situation etwas und höre u. A. Dem Podcast der amerikanischen Korea society und eben diese haben erst vor kurzen einem Podcast veröffentlicht in dem es zu großen Teilen um das 3G Netz geht. Auf das landesinterne Netz hat auch die breite Bevölkerung Zugriff und es hat auch zum Aufbau von kleinen Privatunternehmen beigetragen, da Telefonminuten wie eine Währung zum Kauf und Tausch verwendet werden.
    https://www.koreasociety.org/policy-and-corporate-programs/item/1295-marketization-and-north-korea

  10. während des gesamten Beitrages über Kasachstan denk ich mir “und was ist mit Chrome, Safari, Opera, etc…?”
    Schade, daß Linus die diesbezgl. Nachfrage von Tim ignoriert hat.

  11. Hallo,
    könnte man nicht den SIM2 slot in seinem Schmartphone für eine Secure Storage SIM/Smart Card verwenden? Diese SIM sollte dann verwended werden um 2-factor authentifizierung / Nummerngenerator informationen zu speichern.
    War nur so eine Idee die mir beim hören kam.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Ich akzeptiere

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.