-
121. Data: 2023-12-06 21:23:22
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: Robert Wańkowski <r...@w...pl>
W dniu 06.12.2023 o 21:10, Grzegorz Niemirowski pisze:
> zatrudnianie hakerów.
Taki kod z komputera sterującego pociągiem jak duży może być?
Setki kB?
Robert
-
122. Data: 2023-12-06 21:29:47
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 06.12.2023 o 21:10, Grzegorz Niemirowski pisze:
> io <i...@o...pl.invalid> napisał(a):
>> Wręcz przeciwnie. Niezależny serwis lepiej weryfikuje producenta. To
>> dokładnie wyszło.
>
> Niby tak, ale nie do końca. Wyszło przypadkiem, bo nie jest normalną
> praktyką zatrudnianie hakerów. Poza tym umowa serwisowa nie jest od
> weryfikowania. Nie mówiąc już o tym, że weryfikuje się przed zakupem.
> Wtedy można robić audyty, certyfikacje, odbiory, przeglądy.
>
Moment serwisowania jak najbardziej jest właściwy by ujawniać słabości i
je poprawiać. Podobnież typowy proces wprowadzania oprogramowania przed
wydaniem jest w stanie wykryć wyłącznie podatności znane na moment tego
wydania więc nad bezpieczeństwem systemu pracuje się dalej.
-
123. Data: 2023-12-06 22:11:34
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: "J.F" <j...@p...onet.pl>
On Wed, 6 Dec 2023 20:03:29 +0100, io wrote:
> W dniu 06.12.2023 o 15:47, alojzy nieborak pisze:
>> heby napisał(a):
>>> On 06/12/2023 12:49, alojzy nieborak wrote:
>>>> Jak wydoić PKP. Myk na "zepsuło się" i trza do serwisu.
>>>> https://zaufanatrzeciastrona.pl/post/o-trzech-takich
-co-zhakowali-prawdziwy-pociag-a-nawet-30-pociagow/
>>> Właśnie czytałem. Ciekawe kto za to beknie i czy w ogóle w tym państwie
>>> z kartonu można robić takie numery.
>>
>> Lepiej żeby przetarg na zakup był wiązany z serwisem, wtedy część problemu
rozwiąże się sama.
>
> Wręcz przeciwnie. Niezależny serwis lepiej weryfikuje producenta. To
> dokładnie wyszło.
I tak, i nie.
Najlepiej było kupic pociągi z serwisem np na 1mln km, i niech wygrywa
najtansza/najlepsza oferta.
Tylko 1mln to chyba dla kolei mało, wiec nie wiem - 5 mln plus
rewaloryzacje, czy dlugaśna umowa co producent ma zapewnic i
dostarczyc, aby serwis niezależny był mozliwy ...
J.
-
124. Data: 2023-12-07 01:19:43
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Wed, 6 Dec 2023 22:11:34 +0100
"J.F" <j...@p...onet.pl> wrote:
> On Wed, 6 Dec 2023 20:03:29 +0100, io wrote:
> > W dniu 06.12.2023 o 15:47, alojzy nieborak pisze:
> >> heby napisał(a):
> >>> On 06/12/2023 12:49, alojzy nieborak wrote:
> >>>> Jak wydoić PKP. Myk na "zepsuło się" i trza do serwisu.
> >>>> https://zaufanatrzeciastrona.pl/post/o-trzech-takich
-co-zhakowali-prawdziwy-pociag-a-nawet-30-pociagow/
> >>>>
> >>> Właśnie czytałem. Ciekawe kto za to beknie i czy w ogóle w tym
> >>> państwie z kartonu można robić takie numery.
> >>
> >> Lepiej żeby przetarg na zakup był wiązany z serwisem, wtedy część
> >> problemu rozwiąże się sama.
> >
> > Wręcz przeciwnie. Niezależny serwis lepiej weryfikuje producenta.
> > To dokładnie wyszło.
>
> I tak, i nie.
> Najlepiej było kupic pociągi z serwisem np na 1mln km, i niech wygrywa
> najtansza/najlepsza oferta.
> Tylko 1mln to chyba dla kolei mało, wiec nie wiem - 5 mln plus
> rewaloryzacje, czy dlugaśna umowa co producent ma zapewnic i
> dostarczyc, aby serwis niezależny był mozliwy ...
>
> J.
Przeciez takie umowy (tj na dostarczenie dokumentacji i narzedzi
potrzebnych do niezaleznego serwisu) sa podpisywane, problemem jest
egzekucja tych umow - w tym przypadku dokumentacja byla niekompletna, a
kod zrodlowy nie byl jawny. Zarowno jedno jak i drugie ciezko
wyegzekwowac, nie wykonujac wszystkich krokow z dokumentacji i nie
budujac od zera softu z kodu zrodlowego. A nawet w takim przypadku
pojawia sie pytanie, czy ewentualne problemy sa wina braku kompetencji
sprawdzajacego czy wynikiem faktycznego zaniedbania dostawcy kodu i
dokumentacji.
A serwis wiazany z producentem to slaby pomysl z kilku powodow o
ktorych nie chce mi sie pisac. Faktem jest, ze prawodawstwo unijne
wymusza w tej chwili mozliwosc serwisu przez niezalezne podmioty, i
tego powinnismy sie trzymac.
Niestety odbiory w naszym kraju wykonywane sa niedbale, stad takie
cyrki. Dokladnie to samo jest przeciez z reszta infrastruktury
krytycznej. Najlepszy przyklad - MS Windows, instalowany w praktycznie
kazdym urzedzie.
-
125. Data: 2023-12-07 12:49:58
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: LordBluzg(R)?? <m...@p...onet.pl>
W dniu 07.12.2023 o 01:19, vamastah pisze:
[...]
> Niestety odbiory w naszym kraju wykonywane sa niedbale, stad takie
> cyrki. Dokladnie to samo jest przeciez z reszta infrastruktury
> krytycznej. Najlepszy przyklad - MS Windows, instalowany w praktycznie
> kazdym urzedzie.
A co masz do Windows?
--
LordBluzg(R)??
<<<?i? ć?d?? i Putina i ęjcaredefnoK>>>
-
126. Data: 2023-12-07 18:23:46
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: SW3 <s...@p...fm.invalid>
W dniu 7.12.2023 o 01:19, vamastah pisze:
> Niestety odbiory w naszym kraju wykonywane sa niedbale, stad takie
> cyrki.
Mówisz, że dbały odbiór wykryłby zapis w kodzie oprogramowania, że ten
ma zgłosić awarię, jeśli dzień miesiąca jest większy lub równy 21 oraz
miesiąc jest większy lub równy 11, a rok większy lub równy 2021?
--
SW3
-
127. Data: 2023-12-07 18:26:05
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: "J.F" <j...@p...onet.pl>
On Thu, 7 Dec 2023 18:23:46 +0100, SW3 wrote:
> W dniu 7.12.2023 o 01:19, vamastah pisze:
>> Niestety odbiory w naszym kraju wykonywane sa niedbale, stad takie
>> cyrki.
> Mówisz, że dbały odbiór wykryłby zapis w kodzie oprogramowania, że ten
> ma zgłosić awarię, jeśli dzień miesiąca jest większy lub równy 21 oraz
> miesiąc jest większy lub równy 11, a rok większy lub równy 2021?
Tak, tylko ile by kosztował ?
Ale w NASA sie programy sprawdza, w Boeingu ostatnio też.
J.
-
128. Data: 2023-12-07 21:17:32
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 07/12/2023 18:23, SW3 wrote:
> Mówisz, że dbały odbiór wykryłby zapis w kodzie oprogramowania, że ten
> ma zgłosić awarię, jeśli dzień miesiąca jest większy lub równy 21 oraz
> miesiąc jest większy lub równy 11, a rok większy lub równy 2021?
Ogólnie w poważnej fimie nie da się wprowadzić lewego kodu do
repozyorium bez całej masy zabezpieczeń, wliczajc w to białkowy code
rewiev. A to oznacza, że kilka osób patrzy na ten kod przymusowo, a cał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
w firmie musiało by być uwikłane w tą "konspirację" a więc to żadna
konspiracja, nastepnego dnai przy kawie wiedziałby cały dział.
Oczywiście może być firma bez śladu kontroli jakości kodu. To nawet
bardzo prawdopodobne, firmy piszące w embedded czerpią garściami z lat 80.
Czyli ja widze dwie odpowiedzi:
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
Oba dyskwalifikują firme z poważnych zagadnień.
Jest jeszcze trzecia: wiedział o tym tylko ktoś (+managment), kto
dynamicznie dodawał kod podczas budowania obrazu systemu. Zakładam
jednak, że to już spisek z grubej rury ocierajacy się o prokuraturę. Nie
byli by aż tak głupi, prawda? Prawda?
-
129. Data: 2023-12-07 21:36:21
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: "J.F" <j...@p...onet.pl>
On Thu, 7 Dec 2023 21:17:32 +0100, heby wrote:
> On 07/12/2023 18:23, SW3 wrote:
>> Mówisz, że dbały odbiór wykryłby zapis w kodzie oprogramowania, że ten
>> ma zgłosić awarię, jeśli dzień miesiąca jest większy lub równy 21 oraz
>> miesiąc jest większy lub równy 11, a rok większy lub równy 2021?
>
> Ogólnie w poważnej fimie nie da się wprowadzić lewego kodu do
> repozyorium bez całej masy zabezpieczeń, wliczajc w to białkowy code
> rewiev. A to oznacza, że kilka osób patrzy na ten kod przymusowo, a cał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
> w firmie musiało by być uwikłane w tą "konspirację" a więc to żadna
> konspiracja, nastepnego dnai przy kawie wiedziałby cały dział.
>
> Oczywiście może być firma bez śladu kontroli jakości kodu. To nawet
> bardzo prawdopodobne, firmy piszące w embedded czerpią garściami z lat 80.
Tylko ze "poważna firma" to byłby pewnie Newag.
Bo jakby jakies "koleje regionalne" mialy robic review firmware
pociągu ...
J.
-
130. Data: 2023-12-07 22:12:19
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 07/12/2023 21:36, J.F wrote:
>> Oczywiście może być firma bez śladu kontroli jakości kodu. To nawet
>> bardzo prawdopodobne, firmy piszące w embedded czerpią garściami z lat 80.
> Tylko ze "poważna firma" to byłby pewnie Newag.
> Bo jakby jakies "koleje regionalne" mialy robic review firmware
> pociągu ...
Chodzi o to, że ten zewnętrzny review w tym wypadku jest zbędny, bo
tajemnicy wewnątrz firmy nie da się zachować. Ktoś to zauważy i zapyta w
samym Newagu, a może i doniesie do prokuratory, bo w końcu to jest na
granicy bezpieczeństwa, ingeruje wprost w krytyczne funkcje napędu. Ja
by mieli prawiłowy cykl oczywiście.
Review czy autyt zewnątrzny czasem miałby sens, gdyby szukali bugów. Ale
spisek tego typu byłby widoczny jak na dłoni, w dowolnej fimie z
prawidłowym cyklem tworzenia oprogramowania, tego nei da się łatwo
ukryć. Ja nie widzę opcji utrzymania tego w tajemnicy, chyba że jednak
dziadostwo jakościowe na to pozwoliło. Bo "wszyscy w spisku" brzmi słabo.