Malware-AnalyseundReverseEngineering

13:RückblicküberdasSemester29.6.2017

Prof.Dr.MichaelEngel

Überblick

MARE2017:• EinführungundMotivation,Malware-Historie• Übersetzen undLinken vonProgrammen,Binärformate• LaufzeitverhaltenvonProgrammen,dynamisches Linken• Unix-Prozesse,Programmstart,Stackframes und-verhalten• BufferOverflowsundFunktionsaufrufe• ReturnOrientedProgramming• Schutzmechanismen gegen BufferOverflows• Statische unddynamischeCodeanalyse• PolymorpheViren undselbstmodifizierenderCode• Systemaufrufe• Verhaltensanalyse vonViren• Rootkits

MARE13– Rückblick 2

EinführungundMotivation,Malware-HistorieKurzeGeschichtederComputerviren• DefinitionReverseEngineeringundMalware• HistorievonMalware• Verbreitung• Beispiele• CodeundFunktionsweiseeineseinfachenBeispielvirus• RechtlicheImplikationen

MARE13– Rückblick 3

ÜbersetzenundLinkenvonProgrammen,Binärformate

MARE13– Rückblick 4

Compiliervorgang:• SeparateSchritte:• Übersetzen:.c->.o• Linken:.o->ELF

Binärformate• ELF:Struktur,Sektionen(.text,...)• WerkzeugezurAnalyse(readelf,...)• SymboleundAdressenLinker• Symbole• RelokationenEndianness

LaufzeitverhaltenvonProgrammen,dynamischesLinken

MARE13– Rückblick 5

VirtuellerSpeicherinLinux• Seitentabellen,Umsetzungvirtuelle->physikalischeAdressen• VirtuellesSpeicherlayoutvonProzessenProgrammeundProzesse• Prozessstart:

ÜbergangProgramm->Prozess• Linkerskripte undSpeicherlayoutSpeicherlayoutvonProgrammenzurLaufzeit• DynamischesLinken• Shared Libraries

Unix-Prozesse,Programmstart,Stackframes und-verhalten

MARE13– Rückblick 6

ProzessmodellundProzesserzeugunginUnix• fork undexec,Eltern-/Kindprozesse

Programmstart• Libc,crt0,AufrufundParametervonmainSemantikvonFunktionsaufrufen• ParameterübergabeaufdemStack• Erzeugen undAufbau vonstackframes

• Stack- undFramepointer

BufferOverflowsundFunktionsaufrufe

MARE13– Rückblick 7

Funktionsaufrufeaufx86(32Bit)undx64(64Bit)x86-Linux• Parameterübergabe:Stackvs.Register• FunktionsaufrufinAssembler• FunktiondesBase(Frame)PointersStack-Problemebei C-Funktionen• Lokale undglobale Variable• Lokale Arrays,unsichere libc-Funktionen• BufferOverflowundStackverhaltenAngriffsmethoden• Ausführbarer Stack:Malware-Codeim Buffer“mitliefern”• Nicht ausführbarer Stack:Returntolibc ausnutzen

sub $0x64, %rspmovq %rdi, %rdxmovq %rsp, %rdicallq <memcpy>xor %rax,%raxadd $0x64, %rspretq

ReturnOrientedProgramming

MARE13– Rückblick 8

Ausführbarervs.nichtausführbarerStack-Speicherbereich• DataExecution Protection (DEP=W^X)• Detailszureturn to libcProblembeix64:ParameterübergabeanFunktionen• RegisterstattStack:CodezumSetzenvonRegisternnotwendig• NichtaufStack=>aberCodefragmenteim.text-Segment• Anspringenkurzer„Gadgets“mitReturn(0xc3)amEnde:

Returnoriented programming(ROP)AusnutzenvonROP• FindenvonGadgetsimSpeicher• VerkettenvonGadgetsfürerweiterteFunktionalität• GadgetsmitweitererFunktionalität(nichtnur

LadenvonRegistern)

Schutzmechanismen gegenBufferOverflows

MARE13– Rückblick 9

ErkennenvonBuffer Overflows• Stackcanaries• Stacksmashing protector• SicherheitvoncanariesSchutzvorBuffer Overflows• ShadowstacksSchutzvorROP• Address SpaceLayoutRandomization (ASLR)• DataExecution Prevention (DEP)• DetailszuvirtuellemSpeicherbeix86undAdressumsetzungStatischeCodeanalyse• ModellierungvonStringsundConstraint-Analyse

Statische unddynamischeCodeanalyse (1)

MARE13– Rückblick 10

MehrstatischeCodeanalysen• AnalysevonCodesignaturen(FindenvonBytefolgeninBinaries)• Probleme dersignaturbasierten Erkennung• falsepositivesundfalsenegatives• Größe derSignaturdatenbank undZeitaufwand für Scans

Umgehen derSignaturanalyse• Mutation(Obfuskation)

vonViren:• Einfügen vonNOPs• Codeumsortierung und

Einfügen vonSprüngen• Ersetzen vonInstr.durch semantisch identische Folgen

Original code Obfuscated codeE8 00000000 call 0h E8 00000000 call 0h5B pop ebx 5B pop ebx8D 4B 42 lea ecx, [ebx + 42h] 8D 4B 42 lea ecx, [ebx + 45h]51 push ecx 90 nop50 push eax 51 push ecx50 push eax 50 push eax0F01 4C 24 FE sidt [esp - 02h] 50 push eax5B pop ebx 90 nop83 C3 1C add ebx, 1Ch 0F01 4C 24 FE sidt [esp - 02h]FA cli 5B pop ebx8B 2B mov ebp, [ebx] 83 C3 1C add ebx, 1Ch

90 nopFA cli8B 2B mov ebp, [ebx]

Signature New signatureE800 0000 005B 8D4B 4251 5050 E800 0000 005B 8D4B 4290 51500F01 4C24 FE5B 83C3 1CFA 8B2B 5090 0F01 4C24 FE5B 83C3 1C90

FA8B 2B

Figure 1: Original code and obfuscated code from Chernobyl/CIH, and their corresponding signatures. Newly addedinstructions are highlighted.

E800 0000 00(90)* 5B(90)*8D4B 42(90)* 51(90)* 50(90)*50(90)* 0F01 4C24 FE(90)*5B(90)* 83C3 1C(90)* FA(90)*8B2B

Figure 2: Extended signature to catch nop-insertion.

HareFinally, the Hare virus infects the bootloader sectorsof floppy disks and hard drives, as well as executableprograms. When the payload is triggered, the virusoverwrites random sectors on the hard disk, making thedata inaccessible. The virus spreads by polymorphicallychanging its decryption routine and encrypting its mainbody.The Hare and Chernobyl/CIH viruses are well known

in the antivirus community, with their presence in thewild peaking in 1996 and 1998, respectively. In spiteof this, we discovered that current commercial virusscanners could not detect slightly obfuscated versionsof these viruses.

4 Obfuscation Attacks on CommercialVirus Scanners

We tested three commercial virus scanners againstseveral common obfuscation transformations. To test theresilience of commercial virus scanners to common ob-fuscation transformations, we have developed an obfus-cator for binaries. Our obfuscator supports four com-mon obfuscation transformations: dead-code insertion,code transposition, register reassignment, and instruc-tion substitution. While there are other generic obfus-

cation techniques [11, 12], those described here seemto be preferred by malicious code writers, possibly be-cause implementing them is easy and they add little tothe memory footprint.

4.1 Common Obfuscation Transformations4.1.1 Dead-Code InsertionAlso known as trash insertion, dead-code insertion

adds code to a program without modifying its behav-ior. Inserting a sequence of nop instructions is the sim-plest example. More interesting obfuscations involveconstructing challenging code sequences that modify theprogram state, only to restore it immediately.Some code sequences are designed to fool antivirus

software that solely rely on signature matching as theirdetection mechanism. Other code sequences are com-plicated enough to make automatic analysis very time-consuming, if not impossible. For example, passing val-ues through memory rather than registers or the stackrequires accurate pointer analysis to recover values. Theexample shown in Figure 3 should clarify this. The codemarked by (*) can be easily eliminated by automatedanalysis. On the other hand, the second and third inser-tions, marked by (**), do cancel out but the analysis ismore complex. Our obfuscator supports dead-code in-sertion.Not all dead-code sequence can be detected and elim-

inated, as this problem reduces to program equivalence(i.e., is this code sequence equivalent to an empty pro-gram?), which is undecidable. We believe that manycommon dead-code sequences can be detected and elim-inated with acceptable performance. To quote the docu-

Concept: Abstract the State

● Different abstract interpretations use different abstract states.

● For the signs analysis, each variable could be

● Unknown: either positive or negative (+/-)

● Positive: x >= 0 (0+)

● Negative: x <= 0 (0-)

● Zero (0)

● Uninitialized (?)

● Ignore all other information, e.g., the actual values of variables.

Statische unddynamischeCodeanalyse (2)

MARE13– Rückblick 11

PolymorpheViren• Kombination verschiedenerObfuskationstechnikenKomplexere statische Analyse:Abstrakte Interpretation• Abstraktion vonProgrammzuständen• Abstraktion vonProgrammsemantik• Anwendung:SprunganalyseDynamische Analysen• KontrollflussverfolgungundFunktionsaufruf-

graphen

Polymorphe Viren undselbstmodifizierender Code

MARE13– Rückblick 12

ReverseEngineeringunddasVermeidendavon• ErschwerendesDisassemblierens:SprüngemitteninOpcodes• ArtenvonDisassemblern• LinearSweep vs.Recursive Traversal

• DefinitionundSemantikvonBasisblöckenMehr zu polymorphen Viren• SelbstentschlüsselendeViren• ProblemderBestimmung desaktuellen PC• Obfuskation durch Instruktionsersetzung• SelbstmodifizierenderCode

Systemaufrufe

MARE13– Rückblick 13

SystemaufrufeinLinux• UnterschiedezuundGemeinsamkeitenmitFunktionsaufrufen• SchutzringeundPrivilegienübergang• ÜberblicküberFunktionalitätvon

Systemaufrufen• Systemaufruftabelleund-nummern• Zusammenhang libc <->Systemaufruf

• Systemaufrufe inAssembler• SYSCALL-Befehl• Parameterübergabe und–rückgabe

• Verfolgen vonSystemaufrufen• strace undptrace

Verhaltensanalyse vonViren

MARE13– Rückblick 14

BeobachtendesLaufzeitverhaltensvonProgrammen• Schongesehen:Kontrollflussverfolgung• AnalogiezumImmunsystem• AnalysevonFolgenvonSystemaufrufen• Systemaufruf-Tracesmitlookahead• Einschränkungendeslookahead-Ansatzes• NurSyscall-Nummern(keineParameter)analysiert,kein

Timing,keineAnalysevonausgeführtenInstruktionen• Angriffeauflookahead-Verfahren• Einfügensinn- undnutzloserSystemaufrufe• VerwendenvonSystemaufruf-Folgen,diekürzeralsder

lookahead sind

Rootkits

MARE13– Rückblick 15

PermanentesKompromittiereneinesangegriffenenSystems• InstallationundVerbergenvonMalware-Komponenten• UnterscheidungKernel-/Usermode-Rootkit• VerwendenbereitsbekannteMethoden(z.B.LD_PRELOAD)• Kernelmoduleals Grundlage vonKernelmode-Rootkits

• ErkennungderVeränderung vonBinaries• Checksummingmit Hashfunktionen• Probleme mit Hashfunktionen:Kollisionen inmd5undsha1

• Speicherbasierte Rootkits• Nach Rebootverschwunden,ohne Spuren zu hinterlassen

• VM-basierte Rootkits• Grundlagen HW-Virtualisierung:Ring-1• Beispiel “BluePill”undErkennungsmöglichkeiten

Fazit:Wassolltedasalles?

MARE13– Rückblick 16

KernkompetenzenausderVorlesung• WissenüberdenÜbersetzungsvorgangunddas

LaufzeitverhaltenvonSoftware• Prozesse,Funktions- undSystemaufrufe,Stackverhalten

• TypischeSicherheitslückenundMöglichkeiten,sieauszunutzen• Buffer Overflows,return to libc,ROP,...• TypischeC-Programmierfehler

• Hardware- undSoftware-basierteSchutzmechanismen• DEP,ASLR,statischeunddynamischeCodeanalyse,...

• ...undwiediesewiederumgangenwerdenkönnen...usw.• PolymorpheViren,verschlüsselter/selbstmodif.Code,...

• Definition,StrukturenundFunktionvonRootkits

Fazit:Wassolltedasalles?

MARE13– Rückblick 17

KernkompetenzenausdenpraktischenÜbungen• BessereEinblickeinLinuxaufSystemebene• Compiler,Linker,Shared Libraries,Stackaufbau,ABIs...

• UmgangmitAnalysetools(ELF-Dump,Disassembler,Debugger)• AnalysevonProgrammenaufMaschinenebene• ImplementierungtypischerAngriffe:Buffer overflow,ROP• AnalyseundUmgehenvonSchutzmechanismen:Canaries• ImplementierendynamischerAnalysen:Kontrollflussverfolgung• VerwendenvonSystemaufrufen,ParameterübergabeinASM• Tracing vonSystemaufrufenalsweiteredynamischeAnalyse• VerbergenvonProgrammenalsRootkit-Teilfunktionalität• Hausaufgabe:„Knobeln“mitselbstmodifizierendemCode

Daswar„schon“alles...

MARE13– Rückblick 18