TEKNISKE LÆRINGSPUNKTER FOR UDVIKLERE
Tekniske læringspunkter fra Hostinger-sagen om kategoribaserede detektioner, administrative værktøjer, backupgrænser, scannermetadata og bevaring.
Den tekniske læring rækker ud over én signatur. Dokumentationen berører klassifikation efter funktionalitet, destruktiv oprydning, backupgrænser, ufuldstændig scannermetadata, tredjepartsindsendelse, opbevaring og forskellen mellem en malwarekategori og en påvist skjult payload.
Kategoribaseret detektion og dual-use administrativ funktionalitet
Hostingers afsluttende position behandler filhåndteringen fra august som en kategori for administrative værktøjer baseret på funktionalitet. For udviklere er det væsentligt forskelligt fra en filspecifik påvisning af skjult skadelig kode. Begge forhold kan eksistere samtidig: et sikkerhedsprodukt kan klassificere et kraftfuldt administrativt værktøj i en risikokategori, mens den tilgængelige filspecifikke dokumentation ikke påviser en skjult payload.
Destruktiv oprydning ændrer gendannelsesproblemet
En detektion, der kun advarer, er operationelt anderledes end en detektion, der ændrer eller trunkerer en produktionsfil. Hostinger beskrev oprydningen i august som trunkering til 0 bytes, og sikkerhedskopien efter septemberhændelsen bevarer samme sti med 0 bytes. Systemer, der kan foretage destruktive handlinger, kræver en gendannelsesplan, som tager højde for, at scanneren selv kan blive en del af hændelsen.
Uafhængige hashes er nyttige, men offentliggørelsesstrategien betyder noget
Hashes kan fastslå filidentitet på tværs af uafhængige backups og være værdifulde, når en udbyders registrering er ufuldstændig. De behøver ikke alle at blive offentliggjort med det samme. Denne sagsmappe tilbageholder visse præcise forensiske korrelationer, hvor offentliggørelse ville afsløre relationer til proprietær kildekode eller give udbyderen oplysninger, som den bør kunne producere fra egne systemer.
Bevar forskellige tidskilder i stedet for at normalisere dem gennem antagelser
Tider i scannerinterfacet, karantænetidsstempler, audittidsstempler og backupmærkater kan repræsentere forskellige trin og anvende forskellige tidszoner. Denne sagsmappe offentliggør dem som registreret, medmindre en kilde udtrykkeligt fastslår deres relation. Stiltiende udligning af tidsstempler kan omdanne reel usikkerhed til falsk præcision.
Udbyderens hændelsestabeller indeholder måske ikke de forensiske felter, du forventer
Hostingers afsluttende gennemgang oplyste, at den bevarede hændelsestabel fra august ikke registrerede oprindelig størrelse eller hash, præcis regelversion, scannerkomponent eller matchende byte eller område. Udviklere bør ikke antage, at et sikkerhedsdashboard hos en hostingudbyder indebærer opbevaring af et komplet forensisk hændelsesobjekt. Hvis disse felter er vigtige, bør bevaringsanmodninger være præcise og tidlige.
Tredjepartsindsendelse bør dokumenteres præcist
I denne sag bekræftede Hostinger til sidst indsendelsen af komplette senere/aktuelle filer til CloudLinux gennem Imunify360-værktøjet til falsk-positive indsendelser. Teknisk dokumentation bør skelne mellem den indsendte filversion, tilhørende metadata, tidspunkt, modtagende tjeneste og hvad der fortsat er ukendt om efterfølgende opbevaring eller afledte versioner. Et udsagn om en hash kan ikke erstatte et udsagn om komplet filindhold.