Vzhledem k tomu ze prikazy je mozne spoustet pomoci backdooru (ano je tam base64, ale to neni nic neobvykleho) v EXIF headeru obrazku a funguje ve spojeni s bezne pouzivanou funkci pro praci s obrazky, tak se imho jedna o novou metodu. Alespon ja jsem podobny utok nevidel. Videl jsem par podobnych, kdy kod v obrazku presmeroval uzivatele na jinou stranku, ale to se spise jednalo o spatnou interpretaci obrazku.
Ne, není to útok. Útočník hacknul server a skrz obrázek nainstaloval backdoor. Samotný upload obrázku by mu nepomohl, ještě musel přidat příkaz, který vyextrahuje program z obrázku a spustí ho. Detaily viz váš odkaz.
Osobně to považuji za velmi chytrý způsob ukrytí backdooru. Žádný skrytý proces nebo nějaký root kit. Žádný řádek programu, který by evidentně spuštěl shell s nejakým parametrem.
Je fakt, že takový příspěvky zdánlivě nic nepřináší, ale někoho (mě taky) ta vulnerabilita prostě zabolí a třeba (což je mé, asi marné, zbožné přání) pomůžou tomu, aby se autor trochu zamyslel a třeba začal psát o něco lépe, tedy srozumitelněji. Nebo se nám pak jednou může stát, že nebudem tak úplně klír andrsténdovat běžnýmu čeklengvidž.
Souhlas. Podobné komentáře jsou potřeba už kvůli efektu "já to tak používám už roky a nikdy si nikdo nestěžoval". Stačí jeden a občas, jen aby si autor všiml, že to přeci jen někdy někomu vadí a mohl na tom nějak zapracovat. Osobně si proto myslím, že takové příspěvky přináší autorovi poměrně dost. Čtenářům nic moc, takže raději to nijak zvlášť nerozmazávat.
Čím specifičtější oblast, tím zajímavější terminologie. Znám firmy, kde se bez šopáku nic neudělá. Jak nemáte šopák, tak se nevyrábí. Teprve pohledem do dokumentace zjistíte, že jde o Shop Order. A pohledem do ERP zjistíte, že to není nic jiného než výrobní příkaz. No a teď zkuste české instrukce napsat s "výrobní příkaz" nebo "výrobní zakázka". Málokdo tomu bude rozumět, protože jsou zvyklí na šopák. Obzvláště ti, kteří neumí anglicky.
Takže vulnerabilita je vlastně ještě docela v pohodě. Všichni totiž víme, o čem je řeč.
Mně teda vulnerabilita přišla taky trošku dost, ale nečíst puritány v předchozích diskuzích, tak si toho možná ani nevšimnu. Osobně mi nedělá problém při čtení přepínat mezi jazyky a často jsem radši v českých článcích za anglický termín, protože se pak dobře googlí podrobnosti. Nebo někdy neexistuje česká terminologie - zrovna teď jsem třeba psal článek o Bitcoinu a s tímhle jsem zápasil furt. Nakonec jsem prostě blockchain fork, split keys, mining pool, brainwallet a chainless klient nechal anglicky. Proto prosím, komu to trhá oči, radši to ani nečtěte. Já zase radši přetrpím nějaký ten anglicismus než se vyjadřovat striktně česky na úkor srozumitelnosti. A nesnažte se se mnou IRL bavit o technických tématech, protože uslyšíte česko-anglicko-slovenský mix.
Backdoor ukrytý v obrázku
Myslím, že Martin poměrně přesně vystihl, o co jde, neboť se jedná o celkem primitivní backdoor ukrytý v obrázku, rozhodně ne o steganografický malware, jak se nás marně snaží přesvědčit autor odkazovaného příspěvku, který se pravděpodobně se skutečným steganografickým malwarem zatím asi nesetkal. Ostatně jak takový malware funguje je popsáno v sérii příspěvků “Na obzoru se objevují nové hrozby – třeste se!”: http://www.cleverandsmart.cz/tag/nove-hrozby/.
DDoS
Ano, lze očekávat DDoS útoky o datovém toku až několika desítek Gbps, ovšem s největší pravděpodobností takto masivní útok nebude veden na společnosti v ČR. Zázračné krabičky a cloudová řešení sice mohou většinu společností před tímto útokem ochránit, leč pro většinou z nich by náklady byly výrazně vyšší než možná ztráta plynoucí z několikahodinové nedostupnosti jejich systémů. Tomu nasvědčuje i skutečnost, že ani velké společnosti, se do nákupu těchto řešení nehrnou. Na většinu DDoS útoků se dá docela dobře připravit, ale něco takového tvrdit, není zrovna moc populární: http://www.cleverandsmart.cz/ddos-utoky-v-cr-reseni-misto-straseni/.
Java
Problémy s JAVA asi nikdy neskončí. V okamžiku, kdy budete potřebovat přistupovat na webové stránky, kde se bez Javy neobejdete, např. na stránky internetového bankovnictví, tak v takovém případě doporučuji nainstalovat si ještě jeden prohlížeč a pro něj Javu povolit, a z něj pak chodit jen na tyto stránky a nikam jinam, více viz: http://www.cleverandsmart.cz/zakazte-javu/.
APT
Je pravda, že APT útoky jsou stale důmyslnější, nicméně veškerý malware, který jsme v poslední době zkoumali, fungoval na jednoduchém principu. Zneužil nějaké zranitelnosti, zkopíroval se do nějakého adresáře, z internetu si stáhnul další komponenty a zajistil si své spuštění tím, že se zapsal někam do registru, injektoval nějaký běžící systémový proces, a tím si zajistil svoji trvalou přítomnost v systému. Tyto útoky se však na úniku informací z firem podílejí minimálně, viz příspěvek na Lupě: http://blog.lupa.cz/mce/kyberneticke-utoky-se-na-uniku-informaci-podileji-minimalne/.
ale spolupracuje:
https://www.virustotal.com/en/about/
"VirusTotal and confidentiality
Files and URLs sent to VirusTotal will be shared with antivirus vendors and security companies so as to help them in improving their services and products. We do this because we believe it will eventually lead to a safer Internet and better end-user protection.
By default any file/URL submitted to VirusTotal which is detected by at least one scanner is freely sent to all those scanners that do not detect the resource. Additionally, all files and URLs enter a private store that may be accessed by premium (mainly security/antimalware companies/organizations) VirusTotal users so as to improve their security products and services. "
a mam to i z vlastne zkusenosti:
pri nedavnem pentestu jsem si vytvoril obfuskovany reverzni tcp shell,vygenerovan metasploitem [msfpayload],a ten byl jeste nekolikrat prohnan pres nekolik ruznych urovni randomizace. samozrejme,otestovan na virustototal,s temer nulovou detekci. jaky byl muj udiv,kdyz o par dnu uz AV na cilovem stroji rval,ze podvrzene PDF,ve kterem byl shellcode+payload ukryt obsahuje skodlivy kod,pricemz ten AV je jednim z AV na seznamu na virustotal.com