izsiljevalski virus Locky

@zero_max - včasih se splača tudi prebrati, kaj ti piše v nekem opozorilnem okenčku...

Predvidevam, da se je šlo za čisto banalno opozorilo, ker je excel zaznal, da ima v datoteki eksterne povezave (URL-ja) in te je zato opozoril na MOŽNO nevarnost.
Ne gre se za dejansko analizo povezav, ampak zgolj za obstoj teh. Lahko so popolnoma nedolžne (ki si jih sam dodal...) ali pa zlonamerne, če si xls dobil od neke barabe in ti je noter podtaknil kakšen url, da boš klikal po njemu in si navlekel kakšno nesnago.

Najbolje, da ponoviš vajo z prazno xls datoteko, vanjo vpišeš neke domišlijske (neobstoječe) URL-je (npr. http://soncek123.si/tralala/hopsasa.htm..., shraniš in ponovno odpreš.

SeMiNeSanja je 13. apr 2016 ob 10:31 izjavil:

bastadu je 13. apr 2016 ob 10:18 izjavil:

SeMiNeSanja je 13. apr 2016 ob 09:36 izjavil:

Locky se ne da.... še bolj pasji postaja. http://www.securityweek.com/locky-ranso...

Je kje nkakšen primer, kako dejansko izgleda okužba oz. kaj je treba pognati, da se z njim okužiš?

Klasična varianta je bila že neštetokrat obdelana: preko maila dobiš *.doc ali *.xls datoteko z makroji. Ko jo odpreš in dovoliš makroje, se zadeva aktivira.

Ta novejša varianta pa ne rabi nobenega posebnega posega s strani uporabnika - razen da nevede zaideš na kompromitirano spletno stran. Vse ostalo se potem 'zgodi' v ozadju. http://www.securityweek.com/nuclear-exp... na grobo opisuje, kako deluje nuclear exploit kit. V principu obiščeš kompromitirano spletno stran (lahko čisto legitimna znana stran, kjer vrtijo reklame iz nepreverjenih virov). Kos kode na tej strani (v reklami?) te preusmeri nekam, kjer se preveri ranljivosti, katere podpira tvoj brskalnik (update flash!!!), z njihovo pomočjo na tvoj računalnik prenese tor.exe, ta pa potem potegne tisto dejansko škodljivo kodo... Vse brez uporabnikove interakcije.

Kako to potem deluje, če imaš UAC vklopljen in zahtevaš potrditev uporabnika, da se "tor.exe" lahko zažene?

A ni tako, da ti lahko nastaviš, da mora vsak exe program biti potrjen z uporabnikove strain?

Pa saj to je poanta. Če gre za službene računalnike, uslužbenci itak nimajo kaj za downloadad. Tako da je vseeno, če za vsak, ampak res vsak file vpraša, ali ga dovoli izvesti.

krneki0001 je 8. maj 2016 ob 10:14 izjavil:

A ni tako, da ti lahko nastaviš, da mora vsak exe program biti potrjen z uporabnikove strain?

Ne, razen če uporabiš software restriction policy.

Ampak tudi v tem primeru je uporabnik svojemu browserju že dovolil izvajanje, s tem pa tudi flashu in s tem tudi toru, ki ga ta flash stanka in požene ...

Baje, da sta Dridex in Locky 'down', vsaj začasno.

Nekateri viri pravijo, da je nek whitehat hacker sesul Necurs botnet, ki je prvenstveno zaslužen za širjenje teh nadlog, drugi ugibajo, da je to posledica velike akcije ruskih kriminalistov, ki so polovili 150 članov cyber-kriminalnih združb.

Kakorkoli že, od 1. julija dalje je število novih okužb z Locki in Dridex-om upadlo na ničlo, kar je več kot dobra novica.

Žal je 'in the wild' še vrsta drugih izsiljevalskih škodljivcev, upamo lahko samo, da ne bo že jutri nad nas prišla kakšna še hujša nadloga.

AC_DC je 13. jun 2016 ob 12:57 izjavil:

Trenutno je samo premor pred viharjem :
https://www.fireeye.com/blog/threat-res...

Linkal napačni članek?
Ta v linku govori o tem, da je Angler zdaj sposoben, da ubeži EMET-u. Grda reč. Ampak prav veliko ljudi pa tudi spet ne uporablja EMET.

čuhalev je 16. jun 2016 ob 12:18 izjavil:

Kako te moderne rešitev tipa APT obravnavajo realtime HTTPS promet? Dobro, daš mu certifikat, da lahko prebere. Ampak če je binary velik, potem kaj ... shrani najprej k sebi in ga šele nato ponudi uporabniku?

To je pa odvisno od rešitve do rešitve. Že kaj kdo razume pod pojmom APT zaščita, se razlikuje, še bolj pa potem, kako delajo AV skeniranje ali kakšno Sandbox analizo (če jo sploh).

Že če samo AV skeniranje pogledaš, imaš v osnovi dva različna pristopa - streaming in buffered. Eden je hitrejši, drugi bolj temeljit. V teoriji. V praksi potem pride še v igro, kakšen nabor signatur se sploh uporablja - pri nekaterih rešitvah je ta slabši kot 'skromen'. Ob slabih signaturah, pa potem ne pomaga niti bolj temeljit buffered pristop. Potem je še vprašanje, kakšen AV Engine se sploh uporablja, kako dobra je njegova heuristika, saj se danes škodljivo kodo ujame predvsem s pomočjo heuristike.

V praksi se običajno izkaže, da nosijo malware payload predvsem razmeroma majhne datoteke, tja do 1MB velikosti. Te pa brez težav 'zmelje' tudi vsaka rešitev, ki uporablja buffering metodo za AV skeniranje.

Ko se gre na Sandbox analize, pa so metode še bitveno bolj raznolike. Eni proizvajalci dejansko samo generirajo AV signature na osnovi rezultatov Sandbox analiz in te v bistvu skušajo ščititi preko AV analize. Slabost tega pristopa je ta, da si ranljiv, dokler ne pride naokoli posodobljena AV signatura.
Drugi spet pri vsaki izvedeni analizi dodajo zapis v bazo v 'oblaku'. Ker se najprej preverja, če je bila določena datoteka (glede na njen hash) že kdaj analizirana in kakšen je bil rezultat tega preverjanja, imamo lahko zelo hitre rezultate, ne da bi se kaj dosti rabili ukvarjati s samo datoteko (razen da se generira njeno hash vrednost) - če je bila ta dadoteka že kdaj videna oz. analizirana. V nasprotnem primeru jo je treba poslati v lokalno ali oddaljeno Sandbox analizo.
Nerealno je pričakovati, da bo kdo želel čakati, da pridejo rezultati te analize. Če gledaš stran v brskalniku, morajo biti datoteke dostavljene takoj, ne pa čez 10 min ali bog nedaj dve uri, ko si že pozabil, kaj si sploh brskal.
Zato ti sistemi delujejo v principu bolj kot naknadno opozorilo "Admin, tvoj uporabnik Janez je a strani AAA prenesel datoteko BBB, pri kateri je analiza pokazala potencialno nevarnost...". Tako da potem preide stvar na Admina, da čim prej ukrepa in preveri kaj je dejansko na stvari.

Ker v takem primeru dejansko lahko že pride do okužbe sistema še predenj admin lahko poseže vmes, je še toliko bolj pomembno imeti AV proizvode tudi na računalnikih - in to po možnosti ne iste, kot jih imamo na požarni pregradi. Ta si je namreč datoteko že enkrat ogledal in jo ni prepoznal kot potencialno nevarno.

WatchGuard npr. uporablja kombiniran pristop več različnih varnostnih servisov. - Pri HTTP(s) se najprej preverja, če je vrsta datoteka (content type, extension) sploh dovoljeno prenašati (npr. vsem navadnim uporabnikom prepovemo *.exe in podobno).
- Nato se preveri sam URL, če je na blacklisti pri Websense, oz. spada v dovoljene kategorije glede na svojo klasifikacijo.
- na naslednjem koraku se preveri URL in IP naslov v lastnem RED reputacijskem servisu, ki se napaja iz skeniranj na požarnih pregradah in različnih blacklist (tudi posebna lista podjetja Kasperski, ki pokriva prevsem botnet omrežja).
- šele tu se potem datoteka dejansko prenese in jo podvrže AV skeniranju
- v primeru, da AV skeniranje ne pokaže grožnje, se izvede še preverba hasha v Lastline bazi

Do sem je torej na prenos datoteke vplivalo 5 različnih, med seboj neodvisnih filtrirnih mehanizmov in se njen prenos lahko na vsakem koraku zaustavil, če bi se jo zaznalo kot potencialno grožnjo.

Če preverba hasha v Lastline bazi rezultira v "datoteko ne poznamo, daj pošlji nam jo, da si jo pogledamo bolj podrobno", se jo sprosti uporabniku, saj ta nikakor nebi bil pripravljen čakati 10-20 minut, da se opravi analiza, medtem ko on datoteko potrebuje takoj zdaj.

Pri elektronski pošti seveda odpade preverjanje URL-jev, zato pa nastopi antispam filter. Razlika proti http-ju je tudi v tem, da se datoteko dostavi najprej poštnemu strežniku, od koder jo uporabnik običajno prevzame z časovnim zamikom. Tako obstaja še ena dodatna možnost, da admin datoteko odstrani (po prejemu obvestila iz Sandbox analize, da se gre za potencialno nevarno datoteko), še predenj ta dejansko doseže uporabnika.

Če vse plasti filtriranja pravilno nastavimo, bomo večino najbolj nevarnih datotek zaustavili že na samem začetku, saj jih že v osnovi ne bomo dovolili prenašati, pa če so škodljive ali ne.

Druge rešitve / proizvajalci imajo vsak svoj pristop. Enkrat ti zapakirajo postopek v kakšen zveneč marketinški pojem / slogan, ki pa na koncu ne redko zgolj prikriva kakšno pomanjkljivost v samem pristopu do problematike.

čuhalev je 17. jun 2016 ob 10:09 izjavil:

Sedaj mi je jasno, gre skoraj realtime, le obvestilo zamudi. A headerji (npr PE) se tudi gledajo?

Čisto odvisno od posameznega proizvajalca. Večina jih kaj prav veliko ne gre 'v podrobnosti'.
WatchGuard je tu malo posebneža, ker ima cca. 20 let izkušenj z DPI in ti (poleg ostalega) omogoča tudi strippanje headerjev, ki ti niso po volji in to ločeno za request in response. Headerji so sicer včasih nekoliko sitni, če si strikten, ker se nihče ne drži RFC-ja in vsak spletni programer misli, da se mora ovekovečiti s kakšnim lastnim headerjem.
Če te zanimajo podrobnosti, si lahko prebereš "About the http proxy", kjer je vse razloženo.

čuhalev je 17. jun 2016 ob 10:39 izjavil:

Kako pa je s prilagoditvami? Torej, ali lahko upravljalec doda svoja zaznavna pravila, ko vidi, da željene aplikacije ni na spisku? Sicer sumim, da proizvajalci predpostavljo, da upravljalci niso tega sposobni in teh zmožnosti ni.

Večinoma dejansko ne moreš sam dodajat aplikacijskih signatur in si odvisen od tega, kar ti ponuja proizvajalec.
Tu je potem odvisno, kakšno filozofijo dejansko uporabljaš pri konfiguriranju oz. kakšno ti določen proizvajalec ponudi.
Nek začetnik, ki se ne želi ukvarjati z porti in protokoli, bo bistveno bolj odvisen od samih signatur za aplikacije, saj se bo 'obešal' zgolj na te.

Naprednejši (old-school?) uporabnik pa se drži klasičnega pristopa, da za določeno aplikacijo doda svoje lastno pravilo glede na source/destination/port/protokol in potem za povrhu na to pravilo obesi še aplikacijski filter, da se nebi mogla še kakšna druga reč 'tihotapiti' skozi ta port. Če v takem primeru potem ni ustrezne signature prav za to aplikacijo, tudi ni konec sveta - še vedno namreč lahko prepoveš vse ostale tipične osumljence, da nebi mogli uporabiti to 'luknjo'. Pač nisi ekspliciten, imaš pa še vedno kar solidno zaščito na tem pravilu/portu.