Tak pytam, bo większość wpisu jest o tym co robią te urządzenia i sugestia jak to może być niebezpieczne.
Pod koniec jest test o tym, że nie wchodził dalej.
Na screenach widać tylko jakiś status urządzenia i jego peryferiów. Może zapomniałem, ale nie było widać nawet parametrów którymi się zajmuje urządzenie. Myślałem, że zajmowałeś się czymś podobnym i wiesz. Bo ja jestem sobie w stanie wyobrazić dużo zabezpieczeń chroniących przed zmianą parametrów dopóki ktoś uprawniony nie chce na serio tego zrobić. W końcu nawet w nowoczesnych lokomotywach jest niezła biurokracja fizyczna zanim będziesz miał dostęp do czegoś odpowiedzialnego. https://www.youtube.com/watch?v=5zVH6JSjQKI
“Pod koniec jest test o tym, że nie wchodził dalej.”
Bo to prawnie śliski temat i pewnie bał się konsekwencji gdyby pokazał co tam mógł zrobić.
"Może zapomniałem, ale nie było widać nawet parametrów którymi się zajmuje urządzenie. "
to_zalezy.docx Takie urządzenia potrafią być w miarę uniwersalne i w dokumentacji producent podaje jedynie przykłady użycia, ale w realnej instalacji mogła być użyta tylko jedna funkcja z tego.
“Bo ja jestem sobie w stanie wyobrazić dużo zabezpieczeń chroniących przed zmianą parametrów dopóki ktoś uprawniony nie chce na serio tego zrobić.”
I w sumie tu dochodzimy do ważnego aspektu przy włamaniach do sieci przemysłowych. To, że udało ci się uzyskać dostęp do panelu jakieś automatyki, to połowa sukcesu. Pytanie co chcesz z tym dalej zrobić. Jeżeli faktycznie chciałbyś doprowadzić do większego kryzysu w infrastrukturze krytycznej to potrzebujesz wiedzy jak działa dany proces przemysłowy i jak go popsuć w taki sposób, by narobić szkody i nie podnieść alarmów. Zdecydowanie szerszy zakres wiedzy niż tylko “jak zrobić command injection w panelu WWW”. Chyba w USA był przypadek, gdzie komuś udało się uzyskać dostęp do systemu SCADA odpowiedzialnego za pracę wodociągów w jakieś okolicy. Zdobył uprawnienia, gdzie mógł w teorii tak zakłócić proces, żeby woda w danym rejonie nie nadawała się do spożycia. Problem w tym, że atakujący prawdopodobnie nie miał zielonego pojęcia jak działają takie wodociągi i zaczął różne parametry zmieniać losowo i natychmiast podniósł alarmy w innych systemach, co spowodowało reakcję pracujących tam ludzi.
Możesz też po prostu doprowadzić do zwykłego uszkodzenia przejętych uszkodzeń, jak miało to miejsce jakiś czas temu w Rosji. Oficjalnie do ataku nikt się nie przyznał (ale są podejrzenia). Znaleźli błąd w urządzeniach przemysłowych rosyjskiego producenta, który umożliwiał dostęp do konsoli linuksowej, potem znaleźli ileś takich urządzeń widocznych z internetu. Na każdym urządzeniu odpalili kawałek kodu, który zajeżdżał cyklami zapisu pamięć NAND. W efekcie po jakimś czasie urządzenia zaczęły masowo padać. Jednak skala tego ataku nie była na tyle duża/skoordynowana, żeby wywołało to jakiś blackout.
Myślałem, że od czasów Stuxnet świat wyciągnął wnioski. Że jak chcesz coś zmienić musisz przełączyć urządzenie w odpowiedni tryb, co pociąga za sobą przełączenie infrastruktury i powiadomienia odpowiednich osób. Że zdalne zarządzanie to inny kontroler, domyślnie w trybie RO i bezstanowy. Że zapis do pamięci parametrów jest fizycznie odcięty. Że urządzenia sieciowe mają porównywanie firmware, są resetowane i inne takie. A potem się obudziłem.
"Myślałem, że od czasów Stuxnet świat wyciągnął wnioski. "
@sprae czytający o stanie bezpieczeństwa urządzeń przemysłowych. 2024, drozdowane:
“Że jak chcesz coś zmienić musisz przełączyć urządzenie w odpowiedni tryb, co pociąga za sobą przełączenie infrastruktury i powiadomienia odpowiednich osób.”
Urządzenia Schneidera miały/mają coś takiego. Jak chcesz coś zmienić w urządzeniu, to musisz podejść do niego i takim fizycznym kluczem przestawić w tryb programowania. Tylko jest mały problem. Dopóki takie sterowniki są np na terenie jednego zakładu przemysłowego to możesz się przejść albo poprosić kogoś o przestawienie w tryb programowania. Problem jest wtedy gdy urządzeń jest wiele i są rozsiane po dużym terenie. No więc personel zarządzający tymi sterownikami po prostu cały czas używał ich w trybie programowania. Wykorzystał to malware Triton. Oto poszlaki https://cloud.google.com/blog/topics/threat-intelligence/attackers-deploy-new-ics-attack-framework-triton/
Wygląda jak stare komputery z panelem czołowym do programowania i debugowania.
Temat jest fajną inspiracją do przemyśleń o tym jak sam bym to próbował rozwiązać. Dużo się zastanawiałem nad tym. Jak odcinać komunikację do zmiany parametrów? Jak weryfikować firmware? Jak rozgłaszać zmianę stanu? Gdzie powinien być kompromis wygody? Myślałem raczej o urządzeniach do których musisz podejść jako technik. Bo ich zmiana może być niebezpieczna. Wywoływać straty na dużą skalę.
Na końcu wyszło mi, że miałeś rację i taniej rozwiązują to pewnie dalsze urządzenia, które niezależnie weryfikują pracę i parametry.
Ale ta rozkmina zawsze może się przydać w innych dziedzinach.
Tak pytam, bo większość wpisu jest o tym co robią te urządzenia i sugestia jak to może być niebezpieczne.
Pod koniec jest test o tym, że nie wchodził dalej.
Na screenach widać tylko jakiś status urządzenia i jego peryferiów. Może zapomniałem, ale nie było widać nawet parametrów którymi się zajmuje urządzenie. Myślałem, że zajmowałeś się czymś podobnym i wiesz. Bo ja jestem sobie w stanie wyobrazić dużo zabezpieczeń chroniących przed zmianą parametrów dopóki ktoś uprawniony nie chce na serio tego zrobić. W końcu nawet w nowoczesnych lokomotywach jest niezła biurokracja fizyczna zanim będziesz miał dostęp do czegoś odpowiedzialnego. https://www.youtube.com/watch?v=5zVH6JSjQKI
“Pod koniec jest test o tym, że nie wchodził dalej.”
Bo to prawnie śliski temat i pewnie bał się konsekwencji gdyby pokazał co tam mógł zrobić.
"Może zapomniałem, ale nie było widać nawet parametrów którymi się zajmuje urządzenie. "
to_zalezy.docx Takie urządzenia potrafią być w miarę uniwersalne i w dokumentacji producent podaje jedynie przykłady użycia, ale w realnej instalacji mogła być użyta tylko jedna funkcja z tego.
“Bo ja jestem sobie w stanie wyobrazić dużo zabezpieczeń chroniących przed zmianą parametrów dopóki ktoś uprawniony nie chce na serio tego zrobić.”
I w sumie tu dochodzimy do ważnego aspektu przy włamaniach do sieci przemysłowych. To, że udało ci się uzyskać dostęp do panelu jakieś automatyki, to połowa sukcesu. Pytanie co chcesz z tym dalej zrobić. Jeżeli faktycznie chciałbyś doprowadzić do większego kryzysu w infrastrukturze krytycznej to potrzebujesz wiedzy jak działa dany proces przemysłowy i jak go popsuć w taki sposób, by narobić szkody i nie podnieść alarmów. Zdecydowanie szerszy zakres wiedzy niż tylko “jak zrobić command injection w panelu WWW”. Chyba w USA był przypadek, gdzie komuś udało się uzyskać dostęp do systemu SCADA odpowiedzialnego za pracę wodociągów w jakieś okolicy. Zdobył uprawnienia, gdzie mógł w teorii tak zakłócić proces, żeby woda w danym rejonie nie nadawała się do spożycia. Problem w tym, że atakujący prawdopodobnie nie miał zielonego pojęcia jak działają takie wodociągi i zaczął różne parametry zmieniać losowo i natychmiast podniósł alarmy w innych systemach, co spowodowało reakcję pracujących tam ludzi.
Możesz też po prostu doprowadzić do zwykłego uszkodzenia przejętych uszkodzeń, jak miało to miejsce jakiś czas temu w Rosji. Oficjalnie do ataku nikt się nie przyznał (ale są podejrzenia). Znaleźli błąd w urządzeniach przemysłowych rosyjskiego producenta, który umożliwiał dostęp do konsoli linuksowej, potem znaleźli ileś takich urządzeń widocznych z internetu. Na każdym urządzeniu odpalili kawałek kodu, który zajeżdżał cyklami zapisu pamięć NAND. W efekcie po jakimś czasie urządzenia zaczęły masowo padać. Jednak skala tego ataku nie była na tyle duża/skoordynowana, żeby wywołało to jakiś blackout.
Myślałem, że od czasów Stuxnet świat wyciągnął wnioski. Że jak chcesz coś zmienić musisz przełączyć urządzenie w odpowiedni tryb, co pociąga za sobą przełączenie infrastruktury i powiadomienia odpowiednich osób. Że zdalne zarządzanie to inny kontroler, domyślnie w trybie RO i bezstanowy. Że zapis do pamięci parametrów jest fizycznie odcięty. Że urządzenia sieciowe mają porównywanie firmware, są resetowane i inne takie. A potem się obudziłem.
"Myślałem, że od czasów Stuxnet świat wyciągnął wnioski. "
@sprae czytający o stanie bezpieczeństwa urządzeń przemysłowych. 2024, drozdowane:
“Że jak chcesz coś zmienić musisz przełączyć urządzenie w odpowiedni tryb, co pociąga za sobą przełączenie infrastruktury i powiadomienia odpowiednich osób.”
Urządzenia Schneidera miały/mają coś takiego. Jak chcesz coś zmienić w urządzeniu, to musisz podejść do niego i takim fizycznym kluczem przestawić w tryb programowania. Tylko jest mały problem. Dopóki takie sterowniki są np na terenie jednego zakładu przemysłowego to możesz się przejść albo poprosić kogoś o przestawienie w tryb programowania. Problem jest wtedy gdy urządzeń jest wiele i są rozsiane po dużym terenie. No więc personel zarządzający tymi sterownikami po prostu cały czas używał ich w trybie programowania. Wykorzystał to malware Triton. Oto poszlaki https://cloud.google.com/blog/topics/threat-intelligence/attackers-deploy-new-ics-attack-framework-triton/
Wygląda jak stare komputery z panelem czołowym do programowania i debugowania.
Temat jest fajną inspiracją do przemyśleń o tym jak sam bym to próbował rozwiązać. Dużo się zastanawiałem nad tym. Jak odcinać komunikację do zmiany parametrów? Jak weryfikować firmware? Jak rozgłaszać zmianę stanu? Gdzie powinien być kompromis wygody? Myślałem raczej o urządzeniach do których musisz podejść jako technik. Bo ich zmiana może być niebezpieczna. Wywoływać straty na dużą skalę.
Na końcu wyszło mi, że miałeś rację i taniej rozwiązują to pewnie dalsze urządzenia, które niezależnie weryfikują pracę i parametry.
Ale ta rozkmina zawsze może się przydać w innych dziedzinach.