-
151. Data: 2023-12-08 16:26:07
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 12:43, Grzegorz Niemirowski pisze:
> io <i...@o...pl.invalid> napisał(a):
>> Podpisywanie zapewnia spójność samego oprogramowania, ale Dooma da się
>> wgrać :-)
>
> Od spójności jest suma kontrolna.
W ten sposób nie zweryfikujesz spójności całego systemu, będziesz mógł
dograć moduł, który jest wewnętrznie spójny a jednak nie pasuje do
całego systemu.
> Podpis jest od weryfikowania
> pochodzenia oprogramowania i do odrzucania oprogramowania obcego. I
> jeśli jest weryfikowany, to Dooma nie da się wgrać. Chyba że uda się
> nadpisać sam bootloader i usunąć weryfikację.
>
Czyli, że jednak się da :-) O to mi zasadniczo chodziło bo tak też
tłumaczy Newag. A czy prawdę mówi to ja nie wiem, tylko że faktycznie w
wielu przypadkach da się po prostu wgrać gdy ma się fizyczny dostęp.
-
152. Data: 2023-12-08 16:35:05
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 14:24, J.F pisze:
> On Fri, 8 Dec 2023 12:37:23 +0100, io wrote:
>> W dniu 08.12.2023 o 11:00, heby pisze:
>>> On 08/12/2023 10:27, SW3 wrote:
>>>> W dniu 7.12.2023 o 21:17, heby pisze:
>>>>> 1) jest to takie dzadostwo, że repozytorium kodu nie ma żanych
>>>>> współczesnych metod kontroli jakości
>>>>> 2) wszyscy z dostępem do repo wiedzieli o tej konspiracji
>>>> 3) Ktoś kto bardzo chciał zaszkodzić producentowi, włamał się do
>>>> różnych jego produktów u różnych przewoźników i wgrał oprogramowanie z
>>>> obciążającą go modyfikacją.
>>>
>>> To wymagało by zmian na poziomie kodu maszynowego. Były by widoczne. I
>>> była by to kompromitancja Newagu, że nie podpisują firmware. Bo za
>>> chwile ktoś odpali Dooma na tym pociągu.
>>
>> Podpisywanie zapewnia spójność samego oprogramowania, ale Dooma da się
>> wgrać :-)
>>
>> Z wypowiedzi Newagu można odnieść wrażenie, że nie było podpisywane co
>> oczywiście jest słabe ale wydaje się możliwe. Wcale nie chodzi o
>> "współczesne metody kontroli jakości" tylko o standardy CENELEC, które
>> obecnie muszą spełniać.
>
> Bo po co jakies ambitne podpisywanie, skoro nowy program wgrywa
> autoryzowany serwis?
Tak se właśnie ludzie myślą, że zamknięte pomieszczenie, zamknięta sieć
a to bardziej założenia niż realia. Więc ostatnio jest trend by do tego
implementować normy cybersecurity.
>
>> Zajmowałem się weryfikacją oprogramowania
>> kolejowego w nieco innym obszarze w innej firmie i to wszystko mało
>> poważne było, kierownik bardziej był zainteresowany szybkim wykonywaniem
>> weryfikacji niż jej jakością. Jak dostałem system do weryfikacji, która
>> już wielokrotnie była wykonywana to na wstępie okazało się, że nie
>> wiadomo z jakich modułów składa się system. Po prostu osoby, które
>> wcześniej ją robiły, nie pofatygowały się by określić co dokładnie jest
>> przedmiotem weryfikacji a co nie jest np dlatego, że nie musi. Czyli
>> robiły ją "po łebkach".
>
> Zgodnie z zamówieniem kierownika :-)
Zapewne. Ale też ludzie zajmują się wszystkimi zagadnieniami: piszą
projekty modułów, same moduły, instrukcje, testy, weryfikują. Nie mogą z
wszystkiego być dobrzy.
-
153. Data: 2023-12-08 16:46:28
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 15:50, J.F pisze:
> On Fri, 8 Dec 2023 15:13:31 +0100, io wrote:
>> W dniu 08.12.2023 o 12:22, Grzegorz Niemirowski pisze:
>>> io <i...@o...pl.invalid> napisał(a):
>>>> Gościu w ogóle widział ten kod binarny, że się na jego temat wypowiada?
>>>
>>> Nie musiał.
>>>
>>>> Jeśli np kod czerpał dane z innych zasobów niż z siebie to całe jego
>>>> rozważanie nie ma sensu bo po prostu można źródło podmienić.
>>>
>>> Pociąg pobierał sobie aktualizacje z jakiegoś repo i ktoś to repo
>>> przejął lub zmienił konfigurację pociągu przestawiając na inne repo?
>>>
>> Przeczytaj artykuł z analizą gościa. Twierdzi, że można stwierdzić czy
>> kod wykonywalny powstał ze źródłowego czy ktoś wykonywalny poprawił,
>> sugerując że musiał być ze źródłowego, czyli że Newag go napisał.
>
> A to był ten gościu-hacker, co znalazł te podejrzane miejsca?
No właśnie nie, on tylko rozważa nie widząc tego kodu. A to co jest w
mediach to przecież nie są dokładnie te wstawki jakie zostały znalezione
tylko ich demonstracja.
>
> IMO - w kodzie binarnym mozna conieco podmienic.
> Moze być problem z miejscem, moze trzeba sie będzie bardzo postarać,
> żeby to sensownie wyglądało, ale wykluczyc zmiany nie można.
> Oryginalny programista moze by wychwycił celowość tych zmian,
> ale przed sądem ... bo to wiadomo, który kłamie?
Nie jest pewne, że to w ogóle nadaje się na sąd skoro padło coś o
złamaniu bezpieczeństwa.
>
> No chyba, że kod jakąś sumą kontrolną objęty (co ma sens, ale bardzo
> ambitna musiałaby być),
Sumy kontrolne są liczone standardowo, jak wiesz jak to je policzysz i
podmienisz.
> albo sa pliki z oryginalnym kodem czy
> aktualizacjami, podpisane cyfrowo. ...
No właśnie, i tutaj już da się stwierdzić, że nie jest oryginalne. Ale
jeszcze system musi taki kod odrzucić. Nie jest oczywiste, że to robi. I
co, że ktoś sobie podmienił jeden moduł.
-
154. Data: 2023-12-08 16:47:00
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 15:33, heby pisze:
> On 08/12/2023 15:25, io wrote:
>> wielu przypadkach da się po prostu wgrać gdy ma się fizyczny dostęp.
>
> Mam nadzieję, że te "wiele przypadków" nie dotyczy infrastruktury
> kolejowej.
>
Kto wie, kto wie :-)
-
155. Data: 2023-12-08 18:11:09
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 08/12/2023 15:37, io wrote:
>> One dokładnie wyjasniają w prosty sposób ja bardzo *niemożliwe* jest
>> aby lewy kod dostał się do repozytorium. Nie potrzebujesz nic innego,
>> jak tylko prawidłowe metody pracy z kodem, aby wykluczyć takie numery
>> na poziomie świadomej manipulacji, wstrzyknięcia kodu przez hackerów itd.
> Ale wymaga się standardów a nie "współczesnych metod kontroli jakości"
To jedno i to samo.
Róznica głównie w tym, że standardy mają dużo dodatkowych detali, które
tylko zaciemniają koncept przejrzystości kodu, ale czerpią całymi
garściami z tych współczesnych metod.
> więc po co się rozpędzać. Być może ich nawet nie spełniali, ale też
> kiedy te pociągi były robione, jak odbiorca nie chciał zgodnie ze
> standardem to nie dostał.
Pojmijając kwestie prawne, jestem najzwyczajniej ciekaw, jako
programista właśnie, jak to wygląda od kuchni. Opowieści ludzi, którzy
przeżyli gułagi typu embedded, są straszne.
>> Czyli znowu: ktoś był na tyle głupi, co w świecie embedeed jest normą,
>> że nie wprowadził dobrych metod pisania kodu z całą otoczką code
>> review, coverage, statycznej analizy, podpisywania plików źródłowych i
>> wynikowych i masy innych utrzymujących jakośc i przy okazji
>> eliminujących możliwośc włożenia lewego kodu.
> Mógł weryfikować, ale już zabezpieczenia przed lewym kodem nie zrobił.
Trodno to nazwać zabezpieczeniami. To normalne praktyki w normalnej
firmie programistycznej, ktore *przypadkowo* są również zabezpieczeniem
przed "wstrzykiwaniem" podejrzanwgo kodu. To darmowe ciastko.
>> Najzwyczajniej, jak to bywa w dziadofirmach, "repozytorium" to wspólny
>> katalog na \\dupa\build z kodem zmienianym w czasie rzeczywistym,
>> który kierownik raz dziennie w pocie czoła kompiluje zmawiając
>> jednoczesnie modlitwę.
> Przestań, firmy jednak są dalej. Nie wiem jak dokładnie Newag, ale nie
> mam powodu podejrzewać, że nie.
No, ale jeśli to jednak był:
1) spisek kierownika
2) atak hackerów
To dokładnie tak to wygląda. Nie kontrolują co kompilują i instalują w
pociągach.
A jeśli zrobiono to "gdzieś po drodze", to nie kontroluja jaki kod jest
wykonywany na maszynie.
Każda ewentualnośc świadczy o daleko idącym dziadostwie.
> Na razie nie wiadomo czy to aby na pewno Newag wrzucił. Sam przecież w
> to nie bardzo wierzysz.
Ale szacuję, że to najbardziej prawdopodobne. W sensie: że nie
kontrolowali kodu i jakaś grupa miała pojęcie.
> Ja bym uwierzył nie tyle w to, że to zrobił, ale
> że to mogłoby mieć sens w produktach powszechnego użytku. Gwarantuje 2
> lata to czemu właściwie miałby działać dłużej.
Różnica tutaj jest taka, że skoro to mogło zatrzymać pociąg, to czy aby
na pewno nie potrafiło go uruchomić, albo wyłączyć hamulce, albo
zablokować panel kontrolny albo...
Skala problemu inna, niż podobna funkcjonalnośc w pralce.
-
156. Data: 2023-12-08 19:03:37
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: Piotr Gałka <p...@c...pl>
W dniu 2023-12-08 o 18:11, heby pisze:
> Trodno to nazwać zabezpieczeniami. To normalne praktyki w normalnej
> firmie programistycznej, ktore *przypadkowo* są również zabezpieczeniem
> przed "wstrzykiwaniem" podejrzanwgo kodu. To darmowe ciastko.
Żyję w świecie embedded (choć sam nie napisałem ani jednej linijki kodu
dla procesora) i nie rozumiem o czym piszesz, a chciałbym choć pobieżnie
(na poziomie 'dla idiotów') rozumieć.
Gdzie się mylę?
Procesor ma jakieś złącze do wgrywania kodu (nie chodzi o wykonanie
upgrade, tylko wgrywanie 'od zera').
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ć i jeśli miałby dostęp do sprzętu to nie widzę metody, która
uniemożliwiła by mu wymianę kodu oryginalnego na ten przerobiony.
Skoro hakerzy potrafią się włamać do najpilniej strzeżonych serwerów to
zapewne i do komputera autora tego oprogramowania mogli by się włamać.
Pociągi stoją niby na terenie strzeżonym, ale może 'dla chcącego nic
trudnego'.
> To dokładnie tak to wygląda. Nie kontrolują co kompilują i instalują w
> pociągach.
Jak niby miała by wyglądać kontrola oprogramowania, które ktoś, bez
naszej kontroli nad tym przerobił.
> A jeśli zrobiono to "gdzieś po drodze", to nie kontroluja jaki kod jest
> wykonywany na maszynie.
Znów - jak miałaby wyglądać taka kontrola?
Przecież jak to już jest inny program to on kontroluje wszystko.
> Ale szacuję, że to najbardziej prawdopodobne. W sensie: że nie
> kontrolowali kodu i jakaś grupa miała pojęcie.
Program może sam siebie jakoś kontrolować. Ale jego przerobiona kopia
będzie miała już swoje własne kontrolowanie samej siebie...
P.G.
-
157. Data: 2023-12-08 19:58:03
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 08/12/2023 19:03, Piotr Gałka wrote:
>> Trodno to nazwać zabezpieczeniami. To normalne praktyki w normalnej
>> firmie programistycznej, ktore *przypadkowo* są również
>> zabezpieczeniem przed "wstrzykiwaniem" podejrzanwgo kodu. To darmowe
>> ciastko.
> Żyję w świecie embedded (choć sam nie napisałem ani jednej linijki kodu
> dla procesora) i nie rozumiem o czym piszesz, a chciałbym choć pobieżnie
> (na poziomie 'dla idiotów') rozumieć.
> Gdzie się mylę?
> Procesor ma jakieś złącze do wgrywania kodu (nie chodzi o wykonanie
> upgrade, tylko wgrywanie 'od zera').
Dlaczego to złacze do wgrywania kodu akceptuje dowolny kod? Dlaczego w
ogóle akcpetuje kod?
Dlaczego, z przyczyn bezpieczeństwa, nie wybrano procesora
sprawdzajacego podczas bootowania podpis firmware/flash przed
uruchomieniem kodu? Takie procesory są w powszechnym użyciu.
Jakiś OTP rom, który po wypaleniu (w procku) uniemożliwi wykonanie
niepodpisanego kodu w dalszej częsci flasha. Możesz programować flash na
zdrowie, ale jesli nie podpiszesz, to nie wystartuje.
Przykładem takiego rozwiązania jest konsola Wii, która uniemożliwia
uruchomienie firmware bez podpisu. Jest jednorazowo, w fabryce,
programowana wsadem sprawdzającym podpisy i dalej jest już chain-of-trust.
Zabawne: do dzisiaj nie złamano w pełni tego zabezpieczenia, mimo starań
dziesiątek ludzi. A to zabawka. Znaleziono tylko exploity.
> 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.
Oczywiście, procesor musi mieć taką możliwość. Ale przecież w tych
pociągach nie wstawia się AVRa, prawda?
> i jeśli miałby dostęp do sprzętu to nie widzę metody, która
> uniemożliwiła by mu wymianę kodu oryginalnego na ten przerobiony.
OTP boot rom z kodem kryptograficznym weryfikującym firmware.
https://www.security-embedded.com/blog/2016/7/18/har
dware-software-and-embedded-trust
W takim systemie jedyną drogą dostania się do środka jest exploit.
> Skoro hakerzy potrafią się włamać do najpilniej strzeżonych serwerów to
> zapewne i do komputera autora tego oprogramowania mogli by się włamać.
To jest niebezpieczne. Sam odczyt firmware może prowadzić do procesu
audytu, który szuka exploitów, to znaczące ułatwienie.
Ale brak weryfikacji flasha za pomocą kryptografii jest niedopuszczalny
w krytycznych rozwiązaniach dla bezpieczeństwa.
Świadomość takich rozwiązań jest bliska zeru, w środowisku programatorów
embedded.
>> To dokładnie tak to wygląda. Nie kontrolują co kompilują i instalują w
>> pociągach.
> Jak niby miała by wyglądać kontrola oprogramowania, które ktoś, bez
> naszej kontroli nad tym przerobił.
chain-of-trust.
Nawet PC to implementują od wielu lat. To tylko strach przed aferą na
razie daje nam namiastkę swobody. Przyjdą czasy, że nic poza windowsem
nie uruchomisz, tylko MS będzie mógł podpisać swój bootloader. Z reszta
już przyszło: niektóe komputerki Yoga nie odpalają linuxa. Nie jest
podpisany.
-
158. Data: 2023-12-08 20:19:09
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 19:58, heby pisze:
> On 08/12/2023 19:03, Piotr Gałka wrote:
>>> Trodno to nazwać zabezpieczeniami. To normalne praktyki w normalnej
>>> firmie programistycznej, ktore *przypadkowo* są również
>>> zabezpieczeniem przed "wstrzykiwaniem" podejrzanwgo kodu. To darmowe
...
>
>>> To dokładnie tak to wygląda. Nie kontrolują co kompilują i instalują
>>> w pociągach.
>> Jak niby miała by wyglądać kontrola oprogramowania, które ktoś, bez
>> naszej kontroli nad tym przerobił.
>
> chain-of-trust.
>
> Nawet PC to implementują od wielu lat. To tylko strach przed aferą na
> razie daje nam namiastkę swobody. Przyjdą czasy, że nic poza windowsem
> nie uruchomisz, tylko MS będzie mógł podpisać swój bootloader. Z reszta
> już przyszło: niektóe komputerki Yoga nie odpalają linuxa. Nie jest
> podpisany.
>
>
Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że
pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg
"naprawiony", więc zapomnij.
-
159. Data: 2023-12-08 20:21:33
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 08/12/2023 20:19, io wrote:
> Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że
> pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg
> "naprawiony", więc zapomnij.
Wiec dziadostwo.
-
160. Data: 2023-12-08 20:36:12
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 20:21, heby pisze:
> On 08/12/2023 20:19, io wrote:
>> Więc właśnie tak by to musiało być realizowane a hackerzy twierdzą że
>> pobrali kod, zmodyfikowali i wgrali bez większego trudu, pociąg
>> "naprawiony", więc zapomnij.
>
> Wiec dziadostwo.
>
Ktoś musiałby pilnować kluczy i chronić je przed sprzątaczką :-)
No i dzięki tej podatności niektórzy uświadomili sobie, że oprócz
dobrych rzeczy kod może zawierać również złe, może nawet sprzątaczki :-)