malware-analyse und reverse engineering · malware-analyse und reverse engineering 13: rückblick...
Post on 18-Oct-2020
4 Views
Preview:
TRANSCRIPT
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
top related