The Adventures of the Elusive Malware, del IV: DDE og Word Document Fields

Denne artikkelen er en del av Fileless Malware-serien. Alle andre deler av serien:

• Adventures of the Elusive Malvari, del I
• Elusive Malware Adventures Part II: Hidden VBA Scripts
• The Adventures of the Elusive Malware, del III: Tangled VBA Scripts for Laughter and Profit
• The Adventures of the Elusive Malware, del IV: DDE og Word Document Fields (vi er her)

I denne artikkelen skulle jeg dykke inn i et enda mer komplekst flertrinns filløst angrepsscenario med festing på systemet. Men så kom jeg over et utrolig enkelt angrep uten kode – ingen Word- eller Excel-makroer kreves! Og dette beviser mye mer effektivt min opprinnelige hypotese som ligger til grunn for denne artikkelserien: Å bryte den ytre perimeteren til enhver organisasjon er ikke en vanskelig oppgave i det hele tatt.

Det første angrepet jeg skal beskrive utnytter et Microsoft Word-sårbarhet som er basert på utdatert dynamisk datautvekslingsprotokoll (DDE). Det var hun allerede fikset. Den andre utnytter en mer generell sårbarhet i Microsofts COM- og objektoverføringsfunksjoner.

Tilbake til fremtiden med DDE

Noen andre som husker DDE? Sannsynligvis ikke mange. Det var en av de første kommunikasjonsprotokoller mellom prosesser som tillot applikasjoner og enheter å overføre data.

Jeg er litt kjent med det selv fordi jeg pleide å sjekke og teste telekomutstyr. På den tiden tillot DDE for eksempel callsenteroperatører å overføre anrops-ID til en CRM-applikasjon, som til slutt åpnet et kundekort. For å gjøre dette, måtte du koble en RS-232-kabel mellom telefonen og datamaskinen. Det var tider!

Som det viser seg, er Microsoft Word fortsatt støtter DDE.

Det som gjør dette angrepet effektivt uten kode er at du kan få tilgang til DDE-protokollen direkte fra automatiske felt i et Word-dokument (hatten av for SensePost for forskning og publikasjoner om det).

Feltkoder er en annen gammel MS Word-funksjon som lar deg legge til dynamisk tekst og litt programmering til dokumentet ditt. Det mest åpenbare eksemplet er sidetallfeltet, som kan settes inn i bunnteksten ved å bruke verdien {PAGE *MERGEFORMAT}. Dette gjør at sidetall kan genereres automatisk.

Hint: Du finner menypunktet Felt under Sett inn.

Jeg husker at da jeg først oppdaget denne funksjonen i Word, ble jeg overrasket. Og inntil oppdateringen deaktiverte den, støttet Word fortsatt DDE-feltalternativet. Tanken var at DDE ville tillate Word å kommunisere direkte med applikasjonen, slik at den deretter kunne sende programmets utdata inn i et dokument. Det var en veldig ung teknologi på den tiden – støtte for datautveksling med eksterne applikasjoner. Den ble senere utviklet til COM-teknologi, som vi også skal se på nedenfor.

Etter hvert innså hackerne at denne DDE-applikasjonen kunne være et kommandoskall, som selvfølgelig lanserte PowerShell, og derfra kunne hackerne gjøre hva de ville.
Skjermbildet nedenfor viser hvordan jeg brukte denne stealth-teknikken: et lite PowerShell-skript (heretter referert til som PS) fra DDE-feltet laster et annet PS-skript, som starter den andre fasen av angrepet.

Takk til Windows for popup-advarselen om at det innebygde DDEAUTO-feltet prøver å starte skallet i hemmelighet

Den foretrukne metoden for å utnytte sårbarheten er å bruke en variant med DDEAUTO-feltet, som automatisk kjører skriptet ved åpning Word-dokument.
La oss tenke på hva vi kan gjøre med dette.

Som nybegynner kan du for eksempel sende en phishing-e-post, late som om du er fra Federal Tax Service, og bygge inn DDEAUTO-feltet med PS-skriptet for det første trinnet (i hovedsak en dropper). Og du trenger ikke engang å gjøre noen reell koding av makroer osv., som jeg gjorde i forrige artikkel.
Offeret åpner dokumentet ditt, det innebygde skriptet aktiveres, og hackeren havner inne i datamaskinen. I mitt tilfelle skriver det eksterne PS-skriptet bare ut en melding, men det kan like gjerne starte PS Empire-klienten, som vil gi ekstern skalltilgang.
Og før offeret rekker å si noe, vil hackerne vise seg å være de rikeste tenåringene i landsbyen.

Skallet ble lansert uten den minste bit av koding. Selv et barn kan gjøre dette!

DDE og felt

Microsoft deaktiverte senere DDE i Word, men ikke før selskapet uttalte at funksjonen rett og slett ble misbrukt. Deres motvilje mot å endre noe er forståelig. Etter min erfaring har jeg selv sett et eksempel hvor oppdatering av felt ved åpning av et dokument var aktivert, men Word-makroer ble deaktivert av IT (men viser en melding). Du kan forresten finne de tilsvarende innstillingene i Word-innstillingsdelen.

Men selv om feltoppdatering er aktivert, varsler Microsoft Word i tillegg brukeren når et felt ber om tilgang til slettede data, slik tilfellet er med DDE ovenfor. Microsoft advarer deg virkelig.

Men mest sannsynlig vil brukere fortsatt ignorere denne advarselen og aktivere feltoppdateringen i Word. Dette er en av de sjeldne mulighetene til å takke Microsoft for å ha deaktivert den farlige DDE-funksjonen.

Hvor vanskelig er det å finne et uoppdatert Windows-system i dag?

For denne testen brukte jeg AWS Workspaces for å få tilgang til et virtuelt skrivebord. På denne måten fikk jeg en uoppdatert virtuell MS Office-maskin som tillot meg å sette inn DDEAUTO-feltet. Jeg er ikke i tvil om at du på lignende måte kan finne andre selskaper som ennå ikke har installert de nødvendige sikkerhetsoppdateringene.

Mysterium av objekter

Selv om du installerte denne oppdateringen, er det andre sikkerhetshull i MS Office som lar hackere gjøre noe som ligner veldig på det vi gjorde med Word. I neste scenario vil vi lære bruk Excel som lokkemiddel for et phishing-angrep uten å skrive noen kode.

For å forstå dette scenariet, la oss huske Microsoft Component Object Model, eller for kort COM (komponentobjektmodell).

COM har eksistert siden 1990-tallet, og er definert som en "språknøytral objektorientert komponentmodell" basert på RPC-fjernprosedyrekall. For en generell forståelse av COM-terminologi, les denne posten på StackOverflow.

I utgangspunktet kan du tenke på en COM-applikasjon som en kjørbar Excel- eller Word-fil, eller en annen binær fil som kjører.

Det viser seg at en COM-applikasjon også kan kjøre scenario — JavaScript eller VBScript. Teknisk heter det skriptlet. Du har kanskje sett filtypen .sct for filer i Windows - dette er den offisielle utvidelsen for scriptlets. I hovedsak er de skriptkode pakket inn i en XML-innpakning:

<?XML version="1.0"?>

<scriptlet>
<registration
description="test"
progid="test"
version="1.00"
classid="{BBBB4444-0000-0000-0000-0000FAADACDC}"
remotable="true">
</registration>
<script language="JScript">
<![CDATA[

var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");

]]>
</script>
</scriptlet>

Hackere og pentestere har oppdaget at det er separate verktøy og applikasjoner i Windows som godtar COM-objekter og følgelig også scriptlets.

Jeg kan sende et scriptlet til et Windows-verktøy skrevet i VBS kjent som pubprn. Den ligger i dypet av C:Windowssystem32Printing_Admin_Scripts. Forresten, det er andre Windows-verktøy som godtar objekter som parametere. La oss først se på dette eksemplet.

Det er ganske naturlig at skallet kan lanseres selv fra et trykt skript. Gå til Microsoft!

Som en test laget jeg et enkelt eksternt scriptlet som starter et skall og skriver ut en morsom melding, "Du har nettopp blitt skriptet!" I hovedsak instansierer pubprn et scriptlet-objekt, slik at VBScript-kode kan kjøre en wrapper. Denne metoden gir en klar fordel for hackere som ønsker å snike seg inn og gjemme seg på systemet ditt.

I neste innlegg vil jeg forklare hvordan COM-skript kan utnyttes av hackere som bruker Excel-regneark.

For leksene dine, ta en titt denne videoen fra Derbycon 2016, som forklarer nøyaktig hvordan hackere brukte scriptlets. Og også lese denne artikkelen om scriptlets og en slags moniker.

Kilde: www.habr.com