-
141. Data: 2023-12-08 13:14:46
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 08/12/2023 12:43, Grzegorz Niemirowski wrote:
>> Podpisywanie zapewnia spójność samego oprogramowania, ale Dooma da się
>> wgrać :-)
> Od spójności jest suma kontrolna. 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ę.
To też z drugiej strony tylko teoria. W praktyce prawie każdy system z
podpisywaniem obcego kodu dało się wysypać robiąc nieoczekiwane dla
niego rzeczy, głównie przez wyszukanie exploitów.
Zgaduję jednak, że system embedded do sterowania pociągiem nie powinien
mieć potrzeby ładowana zewnętrznego kodu. Nigdy.
Nawet update firmware powinno odbywać się w serwisie.
-
142. Data: 2023-12-08 13:28:48
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: M M <m...@g...com>
czwartek, 7 grudnia 2023 o 21:18:16 UTC+1 heby napisał(a):
> reszta ma zapewna jakiś poziom wglądu w niego, nawet przypadkiem. Nie
> był on specjalnie ukryty, skoro dekompilacja asm go ujawniła, to musiał
> być czytelny i w kodzie źródłowym. Idąc dalej: to oznacza, że kilka osób
Sprawdzić czy nie został lekko podrasowany kompilator :)
https://home.cs.colorado.edu/~jrblack/class/csci6268
/s14/p761-thompson.pdf
-
143. Data: 2023-12-08 14:02:31
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 08/12/2023 13:28, M M wrote:
>> reszta ma zapewna jakiś poziom wglądu w niego, nawet przypadkiem. Nie
>> był on specjalnie ukryty, skoro dekompilacja asm go ujawniła, to musiał
>> być czytelny i w kodzie źródłowym. Idąc dalej: to oznacza, że kilka osób
> Sprawdzić czy nie został lekko podrasowany kompilator :)
> https://home.cs.colorado.edu/~jrblack/class/csci6268
/s14/p761-thompson.pdf
To chyba nie był jakiś ze stronki kompilatorki.buziaczek.pl tylko co
najmniej kompilowany z podpisanych źródeł, a idealnie, cerytfikowany.
Ogólnie poziom dziadostwa może być dowolny, ale to byłby raczej wtedy
ukierunkowany atak i raczej miał by na celu sabotaż dostaw wojennych niż
konkurencje napraw.
-
144. Data: 2023-12-08 14:24:38
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: "J.F" <j...@p...onet.pl>
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?
> 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 :-)
J.
-
145. Data: 2023-12-08 15:13:31
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
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
wystarczy, że ten kod jednak trochę inny jest niż pokazuje, że np.
korzysta z tablicy dostarczonej z zewnątrz i już tablicę można podmienić
wcale nie modyfikując kodu a sens może być zupełnie inny. Bo pomyśl,
Newag to zgłosił różnym służbom, które na pewno pracowników rozpytały,
sprawdziły to repo i niczego nie znalazły. No chyba, że same były w to
umoczone czego nie da się wykluczyć. Oprócz pracy na repo można sobie
wyobrazić, że ktoś po prostu kod wyniósł na zamówienie.
-
146. Data: 2023-12-08 15:25:23
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. 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.
-
147. Data: 2023-12-08 15:28:48
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: Janusz <j...@o...pl>
W dniu 8.12.2023 o 15:13, io pisze:
> Bo pomyśl, Newag to zgłosił różnym służbom, które na pewno pracowników
> rozpytały, sprawdziły to repo i niczego nie znalazły. No chyba, że same
> były w to umoczone czego nie da się wykluczyć. Oprócz pracy na repo
> można sobie wyobrazić, że ktoś po prostu kod wyniósł na zamówienie.
To że zgłosił nic nie znaczy, wg mnie pali głupa, doskonale wiedział że
jest blokada, świadczy o tym chociażby sekwencja od blokująca z kabiny,
jak się wydało że hakerzy ją wyczaili i uruchomili składy to producent
zdalnie ją zablokował?
Przypadek?
Nie, celowe działanie, cba i inne służby nic z tym nie zrobią bo
ingerencja jest w system sterowania a nie bezpieczeństwa, a to ich
guzik obchodzi. Teraz KD i inne poszkodowane powinny Newag-owi majtki
przez głowę ściągnąć w sądzie.
--
Janusz
-
148. Data: 2023-12-08 15:33:55
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
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.
-
149. Data: 2023-12-08 15:37:34
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 13:00, heby pisze:
> On 08/12/2023 12:37, io wrote:
>> 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"
>
> 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"
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ł.
>
>> tylko o standardy CENELEC, które obecnie muszą spełniać. 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".
>
> 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ł.
Nie bez powodu jest to osobne kryterium weryfikacji zdaje się nawet
wymagane dopiero w wyższych SIL'ach.
>
> 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.
>
> Czy tu było tak? Nie wiem, ale pewne poszlaki wskazują na to, w
> szczególności fakt, że lewy kod powinien być widoczny dla pracowników
> firmy, bo takiej tajemnicy nie da się ukryć w poprawnym flow
> programowania. Więc albo wszyscy wiedzieli, albo flow był do dupy.
> Stawiam na drugie, to firma embedded i to niejako obowiązek każdej firmy
> embedded mieć coś dramatycznie spieprzone we flow.
>
To nie jest tłumaczenie. Firmy mają działy bezpieczeństwa gdzie naprawdę
można zatrudniać ludzi którzy się na tym znają i podczas walidacji
produktu wymagają.
Na razie nie wiadomo czy to aby na pewno Newag wrzucił. Sam przecież w
to nie bardzo wierzysz. 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.
-
150. Data: 2023-12-08 15:50:33
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: "J.F" <j...@p...onet.pl>
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?
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?
No chyba, że kod jakąś sumą kontrolną objęty (co ma sens, ale bardzo
ambitna musiałaby być), albo sa pliki z oryginalnym kodem czy
aktualizacjami, podpisane cyfrowo.
Podpis cyfrowy tez nie daje 100% pewnosci ...
J.