-
161. Data: 2023-12-08 21:03:06
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 08/12/2023 20:36, 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ą :-)
Tak, nie ma nic dziwnego w trzyma niu ich w "sejfie" w postaci
bezpiecznego pomieszczenia z autoryzowanym dostępem.
> 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 :-)
Jak trzymasz zdobycze ostatnich 40 lat informatyki w postaci praktyk
flow kodu w firmie, to większośc z tych problemów najzwyczajniej nie
istnieje.
W tym problem: wiele firm dalej mentalnie siedzi w latach 80 i dalej
kompiluje krytyczny soft z \\dupa\build.
-
162. Data: 2023-12-08 21:28:40
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: io <i...@o...pl.invalid>
W dniu 08.12.2023 o 18:11, heby pisze:
> 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.
Wręcz przeciwnie, te standardy są stare, już dawno miały takie wymagania.
...
>
>> 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,
Nie dało się go odpalić jak za długo stał w serwisie i tyle.
> to czy aby
> na pewno nie potrafiło go uruchomić, albo wyłączyć hamulce, albo
> zablokować panel kontrolny albo...
Oficjalne funkcjonalności tym bardziej rodzą takie wątpliwości.
>
> Skala problemu inna, niż podobna funkcjonalnośc w pralce.
>
Masz bekluczyk w samochodzie?
-
163. Data: 2023-12-08 22:28:40
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Thu, 7 Dec 2023 12:49:58 +0100
LordBluzg(R)?? <m...@p...onet.pl> wrote:
> 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?
>
to samo co do softu w pociagach - brak publicznie dostepnych zrodel
no chyba ze liczymy na to samo co i w ich przypadku, czyli wynajmujemy
sztab hakerow analizujacych binarki
lepszym rozwiazaniem bylby wybor jakiejs komercyjnej dystrybucji Linuxa
i placenie stricte za utrzymanie i pomoc techniczna - chocby z tego
wzgledu, ze nie trzeba uzalezniac sie od monopolu Microsoftu
niestety takie zmiany wchodza w naszym kraju odgornie z inicjatywy UE
(chocby uznanie otwartego ODT za obowiazujacy standard w urzedach), a
nie naszych krotkowzrocznych wladz
-
164. Data: 2023-12-08 22:31:47
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Thu, 7 Dec 2023 18:23:46 +0100
SW3 <s...@p...fm.invalid> 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?
Dbały odbiór pozwoliłby na późniejsze wykrycie tego typu wstawek przez
średnio rozgarnięty zespół programistów, a nie specjalistów zajmujących
się stricte inżynierią wsteczną (których jest na rynku wielokrotnie
mniej)
Poza tym dbały odbiór pozwoliłby na bezproblemowy serwis pociągu z
jakiegokolwiek powodu
-
165. Data: 2023-12-08 22:43:14
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Fri, 8 Dec 2023 20:21:33 +0100
heby <h...@p...onet.pl> wrote:
> 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.
>
no bez jaj, nie widze nic zlego w braku chain-of-trust, to tylko
dodatkowa funkcjonalnosc za ktora de facto nikt nie chce placic, poza
tym zadne mechanizmy weryfikacji autorstwa kodu nic tu nie
rozwiazuja - firma nadal moglaby sie tlumaczyc ze wyciekl jej klucz
prywatny (niczym to sie rozni od gadania ze wyciekl kod zrodlowy)
postawmy sprawe jasno - pociagi sa Newaga, wgrany soft tez (co da sie
udowodnic z wystarczajaca pewnoscia:
https://gynvael.coldwind.pl/?lang=pl&id=777 ), wiec to oni ponosza
odpowiedzialnosc za "babole" w kodzie (ktore de facto sa na ich korzysc)
-
166. Data: 2023-12-08 22:58:17
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: vamastah <s...@w...pl>
On Thu, 7 Dec 2023 22:12:19 +0100
heby <h...@p...onet.pl> wrote:
>
> 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.
>
masz wysokie mniemanie o pracownikach etatowych. Naprawde uwazasz ze
ktokolwiek zglosilby sprawe do organow scigania? Po co sobie robic
problemow?
Swoja droga, pracuje w branzy. W pewnej znajomej firmie robilo sie
pentesty (wg mojej wiedzy skutkujace utrata gwarancji i niewaznoscia
ubezpieczenia) na autach wypozyczonych z wypozyczalni, nie informujac
jej o procederze - co najmniej 10 osob lacznie z managementem o tym
wiedzialo. I co? I nic, nikt normalny nie bedzie sie porywal z motyka na
korporacje.
-
167. Data: 2023-12-08 23:17:12
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
On 08/12/2023 22:43, vamastah wrote:
> no bez jaj, nie widze nic zlego w braku chain-of-trust
Możliwość modyfikacji softu przez kogoś złego.
Z zalet: brak chain-of-trust może być znakomitym dupochronem, bo można
zawsze powiedzieć, że te dodatki do softu, to się same zrobiły "gdzieś
po drodze".
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.
> dodatkowa funkcjonalnosc za ktora de facto nikt nie chce placic, poza
> tym zadne mechanizmy weryfikacji autorstwa kodu nic tu nie
> rozwiazuja - firma nadal moglaby sie tlumaczyc ze wyciekl jej klucz
> prywatny (niczym to sie rozni od gadania ze wyciekl kod zrodlowy)
Jest różnica: jak wycieknie kod źródłowy, to co najwyżej musisz martwić
się o exploity (w systemie offline to nie jest aż tak ważne) ewentualnie
spalasz się ze wstydu jak inni zobaczą co odp... Kaziuk z Januszem w tym C.
Wyciek klucza prywatnego jest niebezpieczny, bo po cichu można dokonać
modyfikacji i doprowadzić do sabotażu.
> postawmy sprawe jasno - pociagi sa Newaga, wgrany soft tez (co da sie
> udowodnic z wystarczajaca pewnoscia:
> https://gynvael.coldwind.pl/?lang=pl&id=777 ), wiec to oni ponosza
> odpowiedzialnosc za "babole" w kodzie (ktore de facto sa na ich korzysc)
Problem już nie dotyczy tego przypadku. Ten przypadek to jest żałosne
kombinowanie będące skokiem na kasę.
Ja się obawiam, że nastepny firmware do tych pociągów może napisać Dima
z Saszą, zamiast Kaziuk z Januszem. I nikt się nie dowie.
Po to powinny być podpisy.
-
168. Data: 2023-12-08 23:20:00
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
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.
-
169. Data: 2023-12-08 23:23:07
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: heby <h...@p...onet.pl>
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.
-
170. Data: 2023-12-09 00:31:30
Temat: Re: Hakowanie infrastruktury za pomocą wyrafinowanych narzędzi
Od: Mirek <m...@n...dev>
On 8.12.2023 23:23, heby wrote:
> Po co komu Linux w pociągu, w komputerze sterujacym jazdą?
>
Taa... jasne.
https://youtu.be/h8OB7ALr9wY?t=32
--
Mirek.