[English]Noch ein kleiner Nachtrag von dieser Woche: Das japanische CERT warnt vor einer neuen Technik von Cyberangreifern, die schädliche Word-Dateien nehmen und in PDF-Dokumente einbetten. Durch dieses "Verpacken" soll die Erkennung der schädlichen Office-Dokumente durch Sicherheitssoftware umgangen werden. JPCERT/CC hat erstmals im Juli 2023 solche als MalDoc bezeichneten Angriffstechniken über infizierte PDF-Dateien beobachtet.
Anzeige
Ich bin bereits vor einigen Tagen auf Twitter über die nachfolgende Meldung des JPCERT/CC gestolpert. Die Sicherheitsbehörde hat das Ganze im Blog-Beitrag MalDoc in PDF – Detection bypass by embedding a malicious Word file into a PDF file dokumentiert.
Dort heißt es, dass JPCERT/CC bestätigt hat, dass bei einem Angriff im Juli 2023 diese neue, MalDoc genannte, Technik verwendet wurde, um die Erkennung von Schaddateien durch Sicherheitssoftware zu umgehen. Dazu wurde eine eine bösartige Word-Datei in eine PDF-Datei einbettet und dann an Opfer verschickt.
Eine mit MalDoc in PDF erstellte Datei kann dabei in Microsoft Word geöffnet werden, obwohl sie die Magic Bytes und die Dateistruktur von PDF-Dokumenten besitzt. Enthält die so maskierte Word-Dokumentdatei ein Makro, wird der VBA-Code beim Öffnen des Dokuments in Word ausgeführt. Dann lassen sich bösartige Aktionen über VBA durchführen.
Anzeige
Interessant ist, dass die bei dem von JPCERT/CC bestätigten Angriff verwendete Dokumentdatei die Dateierweiterung .doc trug, obwohl sie die Magic Bytes sowie die Struktur einer PDF-Datei aufwies. Sobald in den Windows-Einstellungen der Dateityp .doc-Datei so konfiguriert ist, dass dieser in Word geöffnet wird (was ja Standard ist), wird die von MalDoc in PDF erstellte Datei als Word-Datei geöffnet.
Im JPCERT/CC-Beitrag findet sich ein Video, welches den Angriff zeigt. Zudem werden im Blog-Beitrag noch einige Details offen gelegt und die Sicherheitsbehörde gibt einige Hinweise, was man zur Erkennung solcher Schaddateien versuchen kann. Eine sichere Analyse verdächtiger Dokumentdateien wäre das Tool OLEVBA, Zudem haben die Experten der Sicherheitsbehörde eine YARA-Regel zur Erkennung solcher Schädlinge veröffentlicht.
Anzeige
Normalweise blockt der doch Scripte wenn mane eine .doc runterlädt, ausser man gibt sie typischerweise via Kontextmenü frei. Hebelt der auch das aus? (Hab leider keinen PDF Creator sonst würde ich das selbst mal probieren.)
Die Datei ist ein Mine Type multipart.
Das übliche Schlangenöl kennt das nicht und sieht nur den Anfang, was ein PDF ist.
Ein ähnliches Prinzip, zwei Dateien zusammenfügen und dann für den User unerwartete Effekte zu erzielen, gab es früher mit Excel xlsx + xlsm: Der User sah die Endung "xlsx" und vermutete, dass die Datei keine Makros (VBA) enthalten könne.
Wie soll das funktioniert haben? Quelle bitte.
Ist das japanische Cert.
Makros deaktivieren sollte helfen! ?
Das Ganze verwirrt mich etwas, eine PDF, die eine Dateiendung DOC bekommen hat, wird in Word geöffnet und als PDF erkannt und dargestellt und enthält dann nochmal eine DOC mit Makros.
Ich habe das eben mal ausprobiert, jedenfalls so halbwegs, in dem ich eine vorhandene harmlose PDF (aus dem Microsoft PDF "Drucker") in DOC umbenannt habe. Word 365 fragt mich dann welche Codierung für eine historische DOC Datei ich wählen möchte, es wird mir dann "Windows (Standard)", "MS-DOS" und "Andere Codierung" mit vielen Sprachen angeboten. Ich wähle dann das Erste und bekomme dann statt einer 1-Seiten-PDF unzählige Seiten mit Kauderwelsch. Das selbe auch bei "MS-DOS". Wenn ich die Datei als DOCX umbenenne, kann Word sie garnicht mehr öffnen, defekt.
In gut administrierten Firmennetzen ist die Office-Härtung per GPO nach Best Practizes so eingestellt, dass Word alte *.DOC garnicht mehr öffnet.
Ich denke, der Trick funktioniert nur, wenn wirklich eine Word-DOC-Datei in das PDF-Format eingebettet wird – also Magic-Bytes für PDF, aber sonst weitgehend Word-doc-Datei.
Ja.
Einfaches Umbenennen der Endungen hilft natürlich nichts.
irgendwie ist es schon unklar.
Wenn das Dokument als
PDF kommt wird der Adobe Reader die Datei als PDF interpretieren (nur zur Erinnerung: PDF ist eine Programmiersprache…), da die Magic Bytes da sind. In Zug dessen bekommt der PDF Interpreter gesagt, das nun ein embedded doc folgt.
Der PDF Interpreter weiss irgendwoher, dass er an word.exe die nachfolgenden Bytes verfüttern muss. Ich vermute mal durch eine IO-Pipe oder irgendwas MS-erdachtes.
Der übliche Virenscanner bekommt das wahrscheinlich gar nicht mit.
Es erhöht man die Sicherheit seiner Rechner merklich, wenn man den Sumatra Reader anstelle (!) des Adobe Readers einsetzt. Das spart nicht nur etliche 100MB bloatware, sondern auch das rumhuren mit zig Sprachversionen zu je besagten 100eeten Megabytes
Sumatra kommt in 173 Sprachen…und braucht nur wenige MB.
Eine PDF Datei in DOC umzubennen hilft absolut gar nichts.
word sieht seine Magic Zeichen nicht und versucht den PDF Code als Text dazu stellen. Das ist der Kauderwelch.
Word wird auch keinen PDF Reader spawnen, weil Word den PDF Kauderwelsch nicht versteht.
Wäre es möglich durch ein paar Magicbytes andere Programme aufrufen zu lassen, hätte MS da irgendwas nicht so richtig verstanden.
MS hat schon gewusst, warum sie die Entwicklung der Viewer Suite eingestellt hat.
Mit dieser wäre dieser Exploit garnicht möglich gewesen…
ein Schelm der…
HTH.
Ich habe den Sumatra Reader getestet. Leider werden die Firmenlogos auf Lieferscheinen oder Rechnungen von manchen externen Lieferanten nicht korrekt angezeigt. Anstatt dem Firmenlogo sieht man nur ein schwarzes Rechteck. Mit dem Adobe Reader, PDFX-Change usw. werden die PDF-Dateien aber korrekt angezeigt. Hat jemand eine Idee, wie man das in den Griff bekommt?
Habe da ebenfalls Verständnisprobleme:
Also ich lade die Datei mit der Endung .pdf herunter, das System erkennt sie aber als .doc-Datei und öffnet sie entsprechend mit Word oder wie?
So, wie ich das verstanden habe, ist es gerade umgekehrt. Word öffnet eine .doc-Datei, erkennt diese aber wegen der im Header eingebetteten PDF-Informationen als PDF-Datei. Im weiteren Verlauf wird der .doc Inhalt allerdings als solcher verarbeitet. Dabei werden jedoch auch die enthaltenen Word-Makros ausgeführt, weil es für PDF in Word ja keinen Makroschutz gibt und dieser somit ausgehebelt ist.
Jaein
Die Datei kommt mit der Endung doc oder xls.
Der Virenscanner erkennt an dem Magic bytes %pdf das es ein harmloses PDF ist.
Der Virenscanner (Schlangenöl) lässt diese Datei mit der Endung .doc durch.
Outlook startet beim Klicken auf den Anhang word.exe weil .doc damit verbunden ist.
Word ist schlauer als das blöde Schlangen öl und sieht, das hinter dem PDF noch etwas ist.
mime multititype mht.
Und mhts will man nicht haben.
Word sollte den User eigentlich fragen, ob macros ausgeführt werden sollen.
Das ist also Folge davon, das MS versucht den User möglichst zu entmündigen.
Adobe trift keine Schuld
Der Trick bei der Sache ist, dass Programme nicht unbedingt direkt am Anfang der Datei nach ihren bekannten Magic Bytes gucken. So ist es möglich, in einer einzelnen Datei mehrere Dateitypen zu plazieren. Je nachdem, mit welchem Programm die Datei geöffnet wird, wird etwas anderes angezeigt. Die PDF am Anfang soll also nur die Scanner von den Word-Makros ablenken, während Word aber die PDF ignoriert.
Ich konnte das aber auch nicht mal eben so reproduzieren, Word will immer die Datei als Text öffnen. Das Tool "MalDoc in PDF" scheint da noch mehr zu machen als nur die Word-Datei ans Ende anzuhängen.
Und ja, die Datei muss die Endung .doc haben, weil der Benutzer Sie ja in Word öffnen soll.
"Und ja, die Datei muss die Endung .doc haben, weil der Benutzer Sie ja in Word öffnen soll."
Wie kommste darauf?
Die .doc würde ja im dümmsten Filter hängen bleiben.
Selbst der Mitarbeiter mit der tiefsten Inneren Kündigung würde eine fremde .doc nicht mehr öffnen, sofern das überhaupt möglich wäre.
Das muß eine. PDF sein, damit der User vertraut und die PDF öffnet. In der PDF steht dann irgendwo der PDF Befehl, nun bitte das VBA zu entschlüsseln und damit word.exe zu starten. Vermutlich gleich mit den passenden Optionen, die die Macro-Ausführung unmittelbar erlaubt.
Das VBA könnte mit PDF-Code verschlüsselt sein, so das kein übliches Schlangenöl das erkennen kann.
Das Problem ist die Featuritis von Adobe…
270 MB nur zum Lesen in einer Sprache!
ganz so ist ist es doch nicht.
Der Fehler liegt im Schlangenöl.
Die Datei ist mime Multipart.
Die üblichen Scanner können das nicht.
Sie organisieren die Endung und werten nur der ersten Header aus, in dem PDF steht.
Das Schlangen Öl achtet nicht darauf, das die PDF Datei Länger ist und übersieht die mime Deklaration…
Das ist dann das bösartige Word oder Excel Document.
Das Schlangen Öl gibt die Datei frei, denn es ist ja nur ein PDF, auch wenn es .doc oder . xls heißt.
Der User klickt dann auf das .doc.
word sieht das am Anfang ein PDF ist, und springt zum nächsten Mime Header Bingo.
Das kann man eigentlich ganz gut aus dem Link lesen wenn man sich den Hex Code ansieht.
https://blogs.jpcert.or.jp/en/2023/08/maldocinpdf.html
Hast Recht.
ziehe die Frage zurück.
Man muss doch immer erst due Primär Quellen lesen.
Der User muß tatsächlich auf die .doc klicken.
Da er aber weiß, das das von einer sehr teuren Software bereits geprüft wurde, klickt er auf das .doc.
So teure Software muss ja gut sein.
Ich glaube das fällt unter "Risiko Kompensation"
"witzig" ist auch, das der Trick bei .xls nicht so gut funktioniert, weil Excel auffällt, dass die Magic Bytes am Anfang nicht zur Datei-Endung passen und es den User darüber informiert.
Bei Word passiert das nicht.
(Es ist ein kleiner Kunstfehler/Designproblem.
Beim Mac steht der Typ in Resource in der Datei.
Die Datei kann also heißen wie sie will.
Warum hört man so selten von Virus-Problemen beim Mac?
Weil es nicht so viele Systeme gibt oder weil das OS Unix basiert ist?)
Eine Anmerkung zu dem, was hier vor sich geht:
1) es ist eine PDF Datei mit Endung .doc, damit sie mit Word geöffnet wird.
2) Word rendert HTML-Inhalte (einschließlich MHT) unabhängig davon, was davor steht. Einfacher Text ist am besten geeignet.
3) Wenn der MHT-Inhalt ein -Objekt enthält, das auf einen undokumentierten ActiveMime-Blob verweist, dann ist das Ihr Makro!
Beachtet, dass die normalen MotW-aktivierten Makro-Schutzmaßnahmen bestehen bleiben. (Makros auf Dateien aus dem Internet sind heutzutage nicht mehr erlaubt).