I dagens verden af cybersikkerhed afdækkes og offentliggøres et stadig større antal nye sårbarheder (CVE’er) hver dag.
Efterhånden som vores færdigheder og teknologi øges, er vi som samfund blevet bedre til at opdage sårbarheder i forskellige teknologier. Dette gælder naturligvis både for White Hats og Black Hats (også kendt som IT-sikkerhedsprofessionelle og ondsindede hackere). For at forhindre hackere i at misbruge sårbarheder i en organisations software er det fornuftigt at finde disse sårbarheder først og udbedre dem.
Processen med reverse engineering af en binær applikation gør nøjagtigt dette. Nordic Resilience anbefaler en organisation at udføre en reverse engineering af en binær applikation, hvis én eller begge af disse scenarier er gældende:
En organisation har selv udviklet en binær applikation, der eksisterer på flere værter i IT-infrastrukturen eller én enkelt vært i deres DMZ.
- En organisation bruger en binær applikation fra en tredjepart, som ikke har gennemgået en reverse engineering sikkerhedsgennemgang.
- En organisation har selv udviklet en binær applikation, der eksisterer på flere værter i IT-infrastrukturen eller én enkelt vært i deres DMZ.
- En organisation bruger en binær applikation fra en tredjepart, som ikke har gennemgået en reverse engineering sikkerhedsgennemgang.
Hvis Nordic Resilience kontrollerer en tredjeparts binær applikation, bruger vi den såkaldte ansvarlige afsløringsmodel (responsible disclosure model). Denne model dikterer, at vi (Nordic Resilience) kontakter udvikleren af applikationen og deler alle tekniske detaljer om eventuelle sårbarheder, vi opdager. Bagefter får leverandøren en typisk periode på 90 dage til at udbedre/afhjælpe sårbarhederne, før detaljer offentliggøres.
Metoden til udførelse af en reverse engineering-sikkerhedsgennemgang afhænger af den binære applikation:
Generelt består processen med reverse engineering af tre faser:
- Fuzzing af den binære applikation med input for at opdage eventuelle ikke-fangede undtagelser og nedbrud.
- Manuel undersøgelse af nedbrud for at afgøre, om de kan udnyttes til at skabe en sårbarhed.
- Manuel udarbejdelse af en sårbarhed, der kan kompromittere fortroligheden, integriteten og/eller tilgængeligheden.
Hvis der også udleveres kildekode til den binære applikation, kan der udføres yderligere sikkerhedsgennemgange, såsom en (kort) gennemgang af kildekoden for at afgøre, om den inkluderer dårlig kodningspraksis fra et sikkerhedsmæssigt synspunkt. Eksempler på sådanne er:
Efter reverse engineering testen vil organisationen modtage én samlet professionel rapport der indeholder alle observerede sårbarheder og fejlkonfigurationer. Rapporten vil være opdelt i hhv. Et ledelsesreferat og en teknisk sektion. Ledelsesreferatet henvender sig til bestyrelsen, ledelsen og andre interessenter. Den tekniske sektion indeholder uddybende tekniske forklaringer på hver enkelt sårbarheder eller uhensigtsmæssig kodning. Denne sektion henvender sig således til det tekniske personale der skal udbedre observationerne, eventuelt hos en underleverandør.
En reverse engineering af en binær applikation tager som regel 8 dage, men dette afhænger af kompleksiteten af den pågældende binære applikation.