Názory k článku Příchod hackerů: příběh Stuxnetu

Ano, kdysi v pravěku bylo nutné PLC uvést do režimu STOP (kdy nevykonává uživatelský program), aby se přeprogramovalo. To by zabránilo mnohým problémům. Ale nikoliv tomu, který je v článku - prostě by se tam škodlivý kód nahrál v době, kdy tam nahráváte nějakou svou změnu.

Ano, kdysi v pravěku bylo nutné běžet před autem s praporkem. To by zabránilo mnohým dopravním nehodám.

Ale dneska už pravěk není a obě řešení zásadně nevyhovují dnešním potřebám. Je fakt zbytečné vymýšlet dálkově ovládaná tlačítka. Řešení normálního IT světa (heslo, zabezpečený kanál, certifikáty, kontrola hashů) jsou dostatečné.

Nebo "neautomatizační" IT systémy, které jsou mnohy také dost kritické (třeba databáze nějakých enterprise/business systémů) také zamykáte nějakým kouzelným tlačítkem, proti úpravám?

Ta situace se stala v době, kdy - jak už jsem několikrát psal - se na bezpečnost vůči útoku v automatizaci zcela kašlalo. Cesta do PLC byla z místní sítě otevřená dokořán a nějaké speciální programovací tlačítko by na situaci nic nezměnilo.

Takže to čemu vy říkáte kouzelné tlačítko jsou ve skutečnosti jenom digitální opatření. Čili přesně to, co já říkám, že je potřeba a že je dostatečné. Pokud má někdo všechny hesla a certifikáty a je ve správné síti, tak změní nejenom strukturu databáze, ale nainstaluje i patch na DB engine. A v řídících systémech budeme hrozně rádi, když to bude vypadat alespoň takto.
Tlačítko navíc nejenomže není potřeba, ale nic nepřinese - jak už jsem zase několikrát psal.

Tady ale primárně nejde o život a zdraví. Útok na PLC, který by se snažil o to, aby zabil/zranil obsluhu se zatím nekonal. Tady jde zase o ekonomiku. Jaké mám přijmout opatření, aby mi někdo nenarušil můj provoz . A ten provoz může být přímo ta výroba (řídící systém), nebo plánování té výroby (ERP), nebo třeba obchodování (třeba burza). A a útok třeba na systémy burzy by mohl způsobit mnohem větší škodu, než výpadek v nějakém fyzickém provozu (*). Takže provozovatelé těch databází, které "nemohou nikoho zabít" (**), mají paradoxně mnohem větší motivaci k zabezpečení než typický (typický, ne extrémní) průmyslový provoz.

(*) A i než cena odškodnění za zraněné a mrtvé dělníky. Smrt a zranění k lidské fyzické práci patří odnepaměti. A i tady se řeší jak to minimalizovat - a za jakou cenu. Nepochybně i vaše auto ve kterém vozíte vaše děti, by bylo mnohem bezpečnější, kdyby stálo o 2 miliony víc a vážilo o 2 tuny více.

(**) Je to jenom šťournutí, ale když je někde obří ekonomická škoda, tak si vždy nějací lidé vezmou život. Občas ti nejchudší, protože přišli o to málo, občas ti bohatí, protože nezvládnou představu, že by byli chudí.

No. kdysi jsem viděl nějakou detektivku, kde teenager v nemocnici se naboural do jejich databáze a pak likvidoval spolubydlící tím, že jim měnil medikaci. Tímto způsobem může i databáze zabít.

Některé bugy zabíjejí, a nejen v detektivce:
http://en.wikipedia.org/wiki/Therac-25

„ Jinak takováhle databáze pořád nedokáže někoho zabít nebo vážně zranit“

Pokud to není zrovna databáze se zdravotnickými daty…

1) odstředivky jsou "kritický" provoz ve smyslu toho, že výpadky a chyby jsou drahé a oddalují dobu kdy budete mít dost obohaceného materiálu na výrobu bomby. Není to kritický provoz ve smyslu, že hrozí únik radioaktivity mimo provoz.
Pohodlí = ušetřený čas a snížený čas po který provoz nejede = ušetřené peníze a přiblížení doby kýženého cíle.

2) Jestli mám zavirovanou pracovní stanici, tak je zcela irelevantní kolik a jakých tlačítek musím mačkat pro změnu kódu v PLC. Prostě si ten vir počká, až budu dělat nějakou změnu a zmáčknu tlačítko a budu posílat svůj kód, tak se pošle taky.
K čemu mi teda to tlačítko bylo?

Pokud mám zavirovnou pracovní stanici, tak napadení PLCčka škodlivým kódem dlouhodobě nezabráním. Pomůže mi ale kontrola hashů toho, co si myslím, že jsem do PLC nahrál a co tam opravdu nahráno je.

Dovolim si jen upresnit, ze kdyz mate zavirovanou pracovni stanici (tj. notebook s vyvojovym prostredim), tak nepomuze ani kontrola hashu. Ledaze bych je kontroloval z jineho PC.

Jinak souhlas se vsemi Vasimi prispevky. Vypada to, ze mame dost podbnou praxi.

Tak to už by záleželo na inteligenci a povaze toho viru. Jestli by se přidal jenom do paměti PLC, nebo jestli by modifikoval i projekt ve vývojovém prostředí na inženýrské stanici.
Jsem líný to dohledat, ale co si pamatuji, tak na 99% se Stuxnet přidával pouze do paměti PLC.
Ale nevylučuji teoretickou možnost, že by mohl existovat virus, který si bude hlídat správné a špatné hashe a před kompromitovaný hashovací nástroj bude podvrhovat taková čísla, aby to sedělo.
Ale to je fuk - pořád je tam ta možnost udělat to na počítači, kterému věřím, že není zavirovaný.

Tenkrat me to dost zajimalo a mam za to, ze vir nacpal sve instrukce do funkcnich bloku nahranych do PLC a zaroven v napadenem vyvojovem prostredi predstiral, ze tyhle funkcni bloky jsou v poradku. To na tom bylo to zajimave.

Jo to máte asi pravdu. Já si rozhodně vybavuji, že stuxnet našli v PLC, že projekt byl v pořádku :-)
Mne zase hlavně zaujalo, jak poslal první hodnotu na fyzické výstupy a následně ji přepsal na druhou hodnotu tak, že se pro celé okolí tvářil, že na fyzické výstupy byla poslána ta druhá.
Hodně jsem tehdy sledoval blog Ralpha Langnera (jednoho z objevitelů stuxnetu), ale také už si detaily nepamatuji.

Jo, dneska mají dlouhou podporu i některé desktopové distribuce, dříve to bylo jenom pro serverové verze a ještě předtím vůbec. Ale jak jsem psal - dneska to funguje i na linuxu - jenom že na windows to zůstává jako hlavní proud.

U té podpory jde spíš o to jak zajistit spouštění nových věcí na starém OS, než naopak (píšete o spuštění starých věcí na novém OS).
Ale v podstatě jste si odpověděl, proč nepřejít na linux - máte spoustu různých udělátek, které budete na nové windowsy převádět problematicky.
Ale nějak je převedete - nebo přejdete na novou windows verzi od toho výrobce udělátka.

Pokud budete inženýrskou stanici provozovat na linuxu, tak tam z té hromady udělátek nepřevedete bez virtualizace nic a s virtualizací polovinu.
U zbytku zjistítě, že výrobce dodává pouze windows verzi. Spojení výborného HW a šíleného windows-only SW je v automatizaci spíše pravidlem.
A představa, že řeknete - nebudeme používat čerpadla od firmy X a měřáky výkonu od firmy Y a ventily od firmy Z, protože se jejich HW nastavuje jenom ve windows aplikaci - to je úsměvný sen.
Jasné - tohle je věc spíše udržbářského počítače, než inženýrské stanice. Ale většinou to tam musí být taky.

Moc to nechápu.
Stará Windows, nová aplikace - často problém.
Nová Windows, stará aplikace - také často problém.
Linux - v obou případech také často problém, možná trochu častěji, ovšem s možností virtualizovat bez placení a shánění licencí.

Jediné, co beru je ignorantství výrobců hardwaru a nástrojů a díky tomu dodávky softwaru často jen pro Windows. Odstrašujícím případem je třeba Vector Informatics - výborné nástroje, ale jen pro Widle, které se pro to mnohdy ani moc nehodí... A tak se třeba testy automatizují pomocí doinstalovaného Pythonu a nejrůznějších triků a přitom by kolikrát stačil jednoduchý script v Bashi...

Winows mají velmi dlouhou podporu. Například WinXP byly podporované 12 let, a můžete si přikoupit i delší podporu. Windows mají také vynikající zpětnou kompatibilitu, takže budete mít těch problémů relativně málo.

Na Linuxu je situace daleko divočejší: stovky dister, které vychází co pár měsíců, zpětná kompatibilita prakticky neexistuje, ABI pro drivery neexistuje, kernelové moduly je podle autorů jádra nutné uvolňovat pod GPL... Něco z toho sice možná vyřeší použití Red Hat Enterprise Desktopu, ale ten vás vyjde výrazně dráž, než Windows.

Virtualizaci samozřejmě můžete použít i ve Windows. Cena licencí je minimální problém, v ceně projektů naprosto zanedbatelný.

„Například WinXP byly podporované 12 let“

Ne.

MS opravdu podporoval Windows XP 12 let. To samozřejmě nezaručuje, že výrobce SW bude držet stejnou dobu podpory.

V linku se píše o HAPS USB klíči. Pokud ve společnosti Alladin použili nějaké nedokumentované vlastnosti systému, samozřejmě jim driver může přestat fungovat po jakémkoliv patchi. Aplikace ale s HAPS klíči komunikují pomocí klientské knihovny a driveru. Není nic jednoduššího, než si stáhnout aktuální HASP driver, a případně si projít troubleshooting guide.
http://www2.safenet-inc.com/support/files/SafeNet_Sentinel_EndUser_Guide.pdf

Proč je pak potřeba mít starý systém s dlouhou podporou, ve kterém je třeba řešit problémy při aktualizaci, když si můžu pořídit aktuální systém a řešit problémy při aktualizaci?

Pokud stavíte řekněme průmyslový provoz, použijete při tom (většinou) aktuální verzi OS a aplikací. Takový SW pak můžete nechat léta prostě fungovat, jako by byl postavený ze železa. Nejvýš provedete nějaké aktualizace, které nic nerozbijí (ale stejně se před jejich aplikací raději zeptáte výrobce aplikace).

Samozřejmě si po letech můžete pořídit řekněme Windows 8 Embedded místo Windows XP Embedded. Jenže Windows 8 vyžadují více paměti, CPU musí umět PAE, NX a SSE2, a drivery konkrétních zařízení nemusí být kompatibilní. K tomu potřebujete aplikační SW ve verzi kompatibilní s Win8, což s sebou může nést další požadavky na HW nebo SW, nutnost migrace nastavení a kódu...
Aby to bylo zajímavější, IT řeší na původním projektu externí dodavatel, a lidé z provozu ani údržby o věci moc nevědí. Upgrade tedy znamená nutnost rozjet projekt, kde nějaký odborník z externí firmy vyhodnotí, jestli lze použít stávající HW, který SW je nutné upgradovat, co se bude migrovat, jaké změny se budou dělat, jak to ovlivní provoz... A výsledkem celého úsilí bude to, že vám všechno bude fungovat úplně stejně, jako před začátkem upgradu.

A pokud to pak ještě potřebuje nějakou certifikaci, tak už jste úplně ... tam.

Krásně to ukazují ty šílené bedny v rekonstruovaných vozech Metra na trase B. Tam jsou reléové obvody zabezpečováku. A proč to dělali v době mikroprocesorů relátky? Protože ta relátka mají certifikaci a získání nové pro mikroprocesory by vyšlo dráž než nákup nových vagónů i s výměnou zabezpečováku.

Otázka ale pak je, proč na Áčku to šlo. Spíš bych řekl, že důvodem je, že DPP si nemůže dovolit odstavit Béčko na dobu potřebnou ke změně zab.zař.
Ale samozřejmě neznám přímé důvody, pouze moje spekulace.

Na Béčku se ale zabezpečovák neměnil, takže museli někam narvat ty certifikované relátkové obvody.

Něco jiného je pořídit se nový, sériově dělaný zabezpečovák i se všemi certifikacemi (kde se náklady na certifikaci rozpočítají do všech nasazení) a něco jiného je předělat zabezpečovák na koleně a pak chtít certifikaci pro to jedno nasazení, které se už nebude opakovat.

Jehož funkce je navíc ještě očesána, takže po překročení rychlosti umí jen nouzové brždění vedoucí k zastavení vlaku. Původní implementace v 81-71 začala nejdřív brzdit provozně, pokud to bylo neúčinné, došlo k nouzovému brždění.

V pripade PC v nejakem provozu ktere dela neco souvisejiciho s PLC (at uz celkem cokoli), tak mi v tom brani zejmena to PLC, ktereho podpurny SW typicky pro linux neni. A nejak to dobastlovat nebo vybirat dodavatele podle podpory linuxu je samozrejme ekonomicky nesmysl. Koneckoncu PLC jako takove je zarizeni jehoz hlavnim smyslem je, ze je levne (ve smyslu levnejsi nez navrhovat reseni ktere presne odpovida tomu co je v dane aplikaci potreba).

tady se ale zapomíná, že ty systémy virus napadal pomocí 0-day exploitu... kdo zaručí že nic takového nebude na linuxu?
Změnou OS by se nic nevyřešilo, pouze by se změnila platforma na které se virus šíří...
Snad tu nebude nikdo tvrdit, že za posledních 5 let se neobjevila zveřejněna díra v jádře linuxu umožňující něco podobného jako chyba v IE která umožnila "infekci" ...
namátkou nedávno:

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-2523

Reagoval jsem na příspěvěk zobrazený nad Vaším (Petr M (neregistrovaný) ---.honeywell.com).

Díky. Pak jsem na obrazovce použil pravítko a zjistil to taky :-) Doufal jsem, že mi někdo poradí obecně nějaké lepší řešení.

Měkké pravítko - dám pointer na levý okraj příspěvku a kolečkem roluju nahoru až k prvnímu příspěvku, do kterého pointer vleze. Ale není to nic pro Parkinsoniky.