-
171. Data: 2023-12-09 11:25:50
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 09/12/2023 00:31, Mirek wrote:
>> Po co komu Linux w pociągu, w komputerze sterujacym jazdą?
> Taa... jasne.
> https://youtu.be/h8OB7ALr9wY?t=32
To, co widzimy na ekranie, to UI systemu a nie komputer sterujący jazdą.
Mamy wiec co najmniej dwa komputery:
1) sterujacy jazdą
2) panel kontrolny
Ponawiam i multiplikuję pytania:
1) po co w komputerze starujacym jazdą jest Linux?
2) po co w komputerze, wyswietlajacym kilka kółek i prostokątów, jest linux?
To że on tam jest, to czywiste. Ja pytam: po co.
-
172. Data: 2023-12-09 13:27:04
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: Mirek <m...@n...dev>
On 9.12.2023 11:25, heby wrote:
> Ponawiam i multiplikuję pytania:
> 1) po co w komputerze starujacym jazdą jest Linux?
No właśnie nie ma. Przynajmniej w tym newagowskim piszą coś o
architekturze TriCore.
Ale co to znaczy, że on steruje jazdą? To jest raczej odpowiednik ECU w
samochodzie.
>
> 2) po co w komputerze, wyswietlajacym kilka kółek i prostokątów, jest
> linux?
> A na czym byś to zrobił?
--
Mirek.
-
173. Data: 2023-12-09 14:05:51
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: Piotr Gałka <p...@c...pl>
W dniu 2023-12-08 o 19:58, heby pisze:
> Dlaczego, z przyczyn bezpieczeństwa, nie wybrano procesora
> sprawdzajacego podczas bootowania podpis firmware/flash przed
> uruchomieniem kodu? Takie procesory są w powszechnym użyciu.
I już wiem czego nie wiem :)
Jesteśmy na poziomie AtXmega i powoli zaczynamy używać 32 bitowe Silabsy.
Najnowsze mają coś, czego nie ogarnęliśmy, a może być tym o czym piszesz.
> Zabawne: do dzisiaj nie złamano w pełni tego zabezpieczenia, mimo starań
> dziesiątek ludzi. A to zabawka. Znaleziono tylko exploity.
Napisz 1,2 zdania wyjaśniające pojęcie exploit.
>> Jeśli ktoś, jakoś wejdzie w posiadanie całego kodu dla danego
>> urządzenia (w tym przypadku pociągu) to może to oprogramowanie
>> dowolnie zmodyfikować
>
> Wtedy jest niepodpisane. Prawidłowo zaprogramowany kontroler z funkcją
> chain-of-trust *NIE* uruchomi kodu we flash jesli nie zgadza się podpis.
Można też sobie wyobrazić kłopoty z wystarczająco bezpiecznym
przechowaniem klucza do podpisywania i ewentualną możliwość, że ktoś
niepowołany wszedł w posiadanie.
> W takim systemie jedyną drogą dostania się do środka jest exploit.
I znów to słowo :)
> To jest niebezpieczne. Sam odczyt firmware może prowadzić do procesu
> audytu, który szuka exploitów,
...
> Ale brak weryfikacji flasha za pomocą kryptografii jest niedopuszczalny
> w krytycznych rozwiązaniach dla bezpieczeństwa.
Nie wiedząc o istnieniu procesorów, o których piszesz, że są w
powszechnym użyciu wyobrażałem to sobie tak jak my to mamy od 20 lat -
bootloader weryfikuje podpis wsadu, ale wydawało mi się, że każdy procek
ma przez złącze debug dostęp do 'kasujemy wszystko do stanu fabrycznego'.
> Świadomość takich rozwiązań jest bliska zeru, w środowisku programatorów
> embedded.
Jest tyle innych rzeczy zawsze do zrobienia 'na wczoraj'...
P.G.
-
174. Data: 2023-12-09 14:13:34
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: Piotr Gałka <p...@c...pl>
W dniu 2023-12-08 o 23:17, heby pisze:
> Problemem jest zmuszenie prawne do implementacji tego. Prawo tworzą
> przygłupy prawnicze i oni nie ogarną, nawet jak by im ktoś miesiąc
> tłumaczył, że infrastruktura krytyczna powinna mieć jakiś poziom
> zabezpieczeń inny, niż kłódkę i 5 lat w zawieszeniu.
Skojarzenie.
Zamiast wymagać co najmniej pinu do karty to teraz użycie obcej karty do
kupienia czegoś za 10zł nazywa się "przełamaniem zabezpieczeń" i jest
kradzieżą z włamaniem.
P.G.
-
175. Data: 2023-12-09 14:49:41
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 09/12/2023 13:27, Mirek wrote:
>> Ponawiam i multiplikuję pytania:
>> 1) po co w komputerze starujacym jazdą jest Linux?
> No właśnie nie ma.
vamastach postuluje aby był. Pytam po co komu linux w sterowniku napędu.
> Ale co to znaczy, że on steruje jazdą? To jest raczej odpowiednik ECU w
> samochodzie.
Czyli steruja jazdą. Falowniki, hamulce, oddawanie energi (jesli jest) itd.
To powinno być pancerne, prymitywne, małe, wytestowane w 250%. Aby dało
się ograniczyć ilość bugów, które są krytyczne dla bezpieczeństwa.
>> 2) po co w komputerze, wyswietlajacym kilka kółek i prostokątów, jest
>> linux?
>> A na czym byś to zrobił?
Na czymkolwiek do zastosowań embedded i nakierowanym na rysowanie
prostokątów i kółek?
QNX na początek. Potem eCos, czy inny FreeRTOS. Na tym jakakolwiek
bibliteka GUIowa, nawet jakaś prymitywna jak PW lib, czy bardziej
wypasiona Java z Swing w wersji embedded. Qt starało się również wejśc
na rynek embedded ale już tego nie śledzę. Gdzieś był prosty projek
skompilowania wxWidgets na bodaj FreeRTOS, który ktoś zrobił dla zabawy
na jakimś mikrokontrolerze.
Taki system startuje w milisekundy, mieści się we flashu w CPU i szanse
na uszkodzenie są bliskie zeru.
Linux jest zbędny. Tam nie ma zastosowań dla cech, jakie ma linux. To
tylko rysuje prostokąty i kółka i niech robi tylko to. Tak jest
bezpieczniej.
-
176. Data: 2023-12-09 15:06:02
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 09/12/2023 14:05, Piotr Gałka wrote:
>> Zabawne: do dzisiaj nie złamano w pełni tego zabezpieczenia, mimo
>> starań dziesiątek ludzi. A to zabawka. Znaleziono tylko exploity.
> Napisz 1,2 zdania wyjaśniające pojęcie exploit.
Wyobraź sobie, że masz system z implementacją chain-of-trust. Nie da się
uruchomić obcego kodu, wszystko musi być podpisane.
Ale twój system obsługuje USB.
Teraz, złośliwy hacker wie, że masz w tym buga. Na przykłąd nie oczekuje
identyfikatora urządzenia mającego tysiąc znaków. Po prostu programista
nie pomyślał. Typowy problem programatora w C:
char[200]; //should be enough.
W wyniku włożenia spreparowanego urządzenia udajacego pendrive, z
tysiącznakową nazwą, podpisany kod przypadkowo uszkadza sobie stos i
nadpisuje adres powrotu bajtami, które są nazwą urządzenia+kodem do
wykonania.
Tada, nagle odpalasz obcy kod, wykrzystując błąd w kodzie podpisanym.
To exploit.
Prawie każdy kod podpisany miał jakieś explity, dotyczy to głównie
konsol, jeśli chodzi o przykłady, bo tam najwięcej ich znaleziono. No i
są czymś w rodzaju punktu honoru dla crackerów.
Na przykład w konsoli Wii, niektóre gry robiły zapisy na kartę SD. Można
było te zapisy lekko zmodyfikować tak, że gra, poczas odczytu,
wykonywała kod który chciał hacker (bo programatorzy w C nie potrafią
pisać bezpiecznych parserów itd). Kod był wykonywany w konteście
"zaufanego". Zabezpieczenie znika, możesz wykonać swój kod. Nie złamałeś
konsoli (dalej jest to trudne do normalnego używania), ale
chain-of-trust został złamany na jakimś etapie co daje rózne możliwości.
>> Wtedy jest niepodpisane. Prawidłowo zaprogramowany kontroler z funkcją
>> chain-of-trust *NIE* uruchomi kodu we flash jesli nie zgadza się podpis.
> Można też sobie wyobrazić kłopoty z wystarczająco bezpiecznym
> przechowaniem klucza do podpisywania i ewentualną możliwość, że ktoś
> niepowołany wszedł w posiadanie.
To jest tylko problem organizacyjny i radzimy sobie z nim na wiele
sposobów, najczęsciej fizycznych. Ba, istnieją np układy TPM, które
zawierają klucz, ale jednoczesnie zawierają bardzo wyrafine
zabezpieczenia przed jego odczytem (w tym brutalnym, przez decapping).
Wiec nawet jeśli "masz" klucz, bo ukradłeś scalak, to dalej go nie masz
bo go nie ma jak wyciągnąć. Scalak pozwala na podpisanie czegoś, ale nie
pozwala na wyciągnięcie klucza, a przy próbie ingerencji w krzem,
uszkadza go, tracąc na zawsze.
>> Ale brak weryfikacji flasha za pomocą kryptografii jest
>> niedopuszczalny w krytycznych rozwiązaniach dla bezpieczeństwa.
> Nie wiedząc o istnieniu procesorów, o których piszesz, że są w
> powszechnym użyciu wyobrażałem to sobie tak jak my to mamy od 20 lat -
> bootloader weryfikuje podpis wsadu, ale wydawało mi się, że każdy procek
> ma przez złącze debug dostęp do 'kasujemy wszystko do stanu fabrycznego'.
Nie. To odróżnia procesory bezpieczne, do zastosowań krytycznych, od
niebezpiecznych.
Ja nie wiem co Newag używa, ale bez względu na to co uzywa: skoro
hackerzy dali radę zmienic wsad i go wgrać, to oznacza, że używają
mikrokontrolera do migania diodami w celu napędzania infrastruktury
krytycznej.
-
177. Data: 2023-12-09 15:06:53
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 09/12/2023 14:13, Piotr Gałka wrote:
>> Problemem jest zmuszenie prawne do implementacji tego. Prawo tworzą
>> przygłupy prawnicze i oni nie ogarną, nawet jak by im ktoś miesiąc
>> tłumaczył, że infrastruktura krytyczna powinna mieć jakiś poziom
>> zabezpieczeń inny, niż kłódkę i 5 lat w zawieszeniu.
> Skojarzenie.
> Zamiast wymagać co najmniej pinu do karty to teraz użycie obcej karty do
> kupienia czegoś za 10zł nazywa się "przełamaniem zabezpieczeń" i jest
> kradzieżą z włamaniem.
Czy już wspomniałem, że prawo tworzą prawnicze przygłupy?
-
178. Data: 2023-12-09 16:01:03
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Fri, 8 Dec 2023 23:23:07 +0100
heby <h...@p...onet.pl> wrote:
> On 08/12/2023 22:28, vamastah wrote:
> > lepszym rozwiazaniem bylby wybor jakiejs komercyjnej dystrybucji
> > Linuxa
>
> Nie wiem czy mowa dalej o pociągach, ale jesli tak:
>
> Po co komu Linux w pociągu, w komputerze sterujacym jazdą?
>
> Ja rozumiem, do sterowania tablicami informacyjnymi, routerami wifi,
> czy wodą w kiblu.
>
> Ale jazdą? Tam powinien być najmniej skomplikowany jak się da, wręcz
> na poziomie sterownika, maluteńki komputerek. Z kodem dającym się
> ogarnąc formalną weryfikacją, z coverage 100%, z lintem na 0
> problemów.
>
Cytat bardzo wyraznie tyczyl sie alternatywy dla Windowsa i Microsoftu
w urzedach. Co do sterowania jazda, nie widze pola do wiekszej dyskusji
- Linux nadaje sie rowniez i do tego, sa dostepne odpowiednie patche
zapewniajace funkcjonalnosc systemu czasu rzeczywistego (PREEMPT_RT),
choc rownie dobrze mozna by bylo zastosowac dowolny inny (m.in.
Zephyr czy FreeRTOS). W pisanie na baremetal nikt rozsadny by sie nie
pchal, znajac dynamiczne srodowisko biznesowe w branzy embedded (no
chyba ze biznes programisty nie interesuje, co w pelni rozumiem).
-
179. Data: 2023-12-09 16:03:40
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Fri, 8 Dec 2023 23:20:00 +0100
heby <h...@p...onet.pl> wrote:
> On 08/12/2023 22:58, vamastah wrote:
> > masz wysokie mniemanie o pracownikach etatowych. Naprawde uwazasz ze
> > ktokolwiek zglosilby sprawe do organow scigania? Po co sobie robic
> > problemow?
>
> Nie. Po prostu zesrają się na widok policji w firmie.
>
> To tylko nerdy. Mogą trzymać mordę na kłódkę, ale siedzienie na dołku
> i bycie przesłuchiwanym już nie jest takie fajne jak na filmach.
>
> Innymi słowy: utrzymanie tego w tajemnicy jest niemożliwe, jak już
> się mleko rozleje.
>
> Ponoć rozlało się w maju, tako mówi ktoś ważny z ministerstwa, jak
> dzisiaj wyciekło.
>
Zgadza sie, nikt nikogo kryc nie bedzie, natomiast nikt tez sie nie
bedzie wyrywac, by takie sprawy gdziekolwiek zglaszac. Przesluchiwany
moze byc co najwyzej zarzad i wyzej postawione osoby w firmie, rotacja
wsrod szeregowych pracownikow jest na tyle wysoka, ze nikt nie
powinien zawracac sobie nimi glowy - a nawet jesli, to sie od nich
nie dowie niczego, czego nie wiedzial wczesniej.
-
180. Data: 2023-12-09 16:11:22
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Sat, 9 Dec 2023 15:06:02 +0100
heby <h...@p...onet.pl> wrote:
>
> Ja nie wiem co Newag używa, ale bez względu na to co uzywa: skoro
> hackerzy dali radę zmienic wsad i go wgrać, to oznacza, że używają
> mikrokontrolera do migania diodami w celu napędzania infrastruktury
> krytycznej.
>
Nie, nie oznacza. Byla mowa wczesniej o tym, ze wykorzystuja
architekture TriCore, a ona jak najbardziej wspiera Secure Boot
(mikrokontrolery tej rodziny maja zwykle wbudowanego HSMa). Trzeba to
tylko odpowiednio skonfigurowac. Ponadto to nie sa zabawki i maja wiele
innych mechanizmow security (np blok CERBERUS do kontroli dostepu do
portu debugowego).
Komus sie po prostu nie chcialo / nie oplacalo tego implementowac.