eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronika › Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Ilość wypowiedzi w tym wątku: 306

  • 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.

strony : 1 ... 10 ... 14 . [ 15 ] . 16 ... 30 ... 31


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: