Tylna furtka w Juniper od 3 lat

same nowosci
Wiadomość
Autor
Marek607
wannabe
wannabe
Posty: 146
Rejestracja: 02 gru 2014, 10:38
Lokalizacja: Kutno
Kontakt:

Tylna furtka w Juniper od 3 lat

#1

#1 Post autor: Marek607 »

Hej.

http://forums.juniper.net/t5/Security-I ... a-p/285554

https://zaufanatrzeciastrona.pl/post/ko ... -od-3-lat/

Czas na przedświąteczne okienko serwiowe :wink:
Swoją drogą - nie chce mi się wierzyć że przez tyle lat nie zlokalizowali tak dużej luki.....

michaliwanczuk
wannabe
wannabe
Posty: 187
Rejestracja: 17 kwie 2010, 21:48
Kontakt:

#2

#2 Post autor: michaliwanczuk »

kiedyś słyszałem że nadal jest tylna furtka w urządzeniach Checkpoint dla NSA ale nie wiem czy to prawda czy tylko plotka
Michał

Awatar użytkownika
Sofcik
wannabe
wannabe
Posty: 1026
Rejestracja: 28 mar 2006, 15:29
Lokalizacja: Warszawa

#3

#3 Post autor: Sofcik »

Większość nowego sprzętu nie jest na ScreenOS, a na JunOS. Swoją droga ciekawe czy i w tym sofcie są jakieś "niespodzianki" bo wtedy mielibyśmy kłopot praktycznie ze wszystkim (SRX, M, J, EX i cała reszta...)

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#4

#4 Post autor: lbromirs »

Sofcik pisze:Większość nowego sprzętu nie jest na ScreenOS, a na JunOS. Swoją droga ciekawe czy i w tym sofcie są jakieś "niespodzianki" bo wtedy mielibyśmy kłopot praktycznie ze wszystkim (SRX, M, J, EX i cała reszta...)
Sposób w jaki to wyszło, podkreśla to co powtarzaliśmy jako Cisco nie tylko w stosunku do Junipera od lat - brak jasnego i udokumentowanego procesu 'lifecycle' dla oprogramowania, którego elementarną cześcią jest przeglądanie kodu - gryzie w tyłek. Jeśli do tego nie wszystkie problemy są oficjalne, nie ma jasnej i przejrzystej polityki ich publikowania (w szczególności tych związanych z bezpieczeństwem) - też nie jest dobrze.

Oby dla Junipera była to taka nauczka, z której w końcu wyciągnie właściwe wnioski.

b4n3
wannabe
wannabe
Posty: 128
Rejestracja: 25 cze 2010, 09:58

#5

#5 Post autor: b4n3 »

Spoko, a CISCO nie miało swoich problemów.. ;)
Temat dotyczy urządzeń end of life od dawna, a jednak wrzucili poprawkę.
Dodatkowo aby móc odpalić sesję SSH trzeba było być w permitted IP jako manager, to jedno. Kolejna sprawa to należy znać nazwę konta, które istnieje w systemie aby móc użyć tego hasła.
Każdy vendor ma swoje podatności o których nie wie lub jeszcze nie chce wiedzieć..

Marek607
wannabe
wannabe
Posty: 146
Rejestracja: 02 gru 2014, 10:38
Lokalizacja: Kutno
Kontakt:

#6

#6 Post autor: Marek607 »

Nie słyszałem o takowych ( prócz ostatniego problemu z obudową do wtyczki rj45 ;)

https://community.rapid7.com/community/ ... n-backdoor

złamać to brute-forcem nie byłoby prosto ;)

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#7

#7 Post autor: lbromirs »

b4n3 pisze:Spoko, a CISCO nie miało swoich problemów.. ;)
Backdoor w IOSie? Pokaż mi proszę gdzie konkretnie, najlepiej z URLem.

Problem, do którego Juniper się przyznał jest dużo bardziej fundamentalny. Ale wygląda na to, że już wyciągają z tego wnioski - i dobrze.

Binkz
fresh
fresh
Posty: 8
Rejestracja: 16 gru 2010, 15:39

#8

#8 Post autor: Binkz »

b4n3 pisze:Kolejna sprawa to należy znać nazwę konta, które istnieje w systemie aby móc użyć tego hasła.
Aż z ciekawości sprawdziłem to w labie.

https://zaufanatrzeciastrona.pl/post/ha ... nipera-to/

Uzyskałem dostęp do pudełka po ssh używając hasła:

Kod: Zaznacz cały

<<< %s(un='%s') = %u
dla użytkownika root.

Wersja softu 6.3.0r17

crusty
wannabe
wannabe
Posty: 92
Rejestracja: 05 sty 2006, 00:01
Lokalizacja: Warszawa

#9

#9 Post autor: crusty »

lbromirs pisze:
b4n3 pisze:Spoko, a CISCO nie miało swoich problemów.. ;)
Backdoor w IOSie? Pokaż mi proszę gdzie konkretnie, najlepiej z URLem.

Problem, do którego Juniper się przyznał jest dużo bardziej fundamentalny. Ale wygląda na to, że już wyciągają z tego wnioski - i dobrze.
Ja np. Natknąłem się na takie info o Cisco źródło- uk.businessinsider.com

But it was Juniper's arch rival, Cisco, who took more heat for having products that were allegedly being tampered with so various governments can spy. In 2014, a photo circulated that allegedly showed Cisco devices being intercepted and tampered with by NSA techs. After that, Cisco's Chinese sales tanked, over fears of US government spying.

Cisco's then CEO John Chambers even wrote an open letter to President Obama asking Obama to stop the NSA from hacking into Cisco's equipment.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#10

#10 Post autor: lbromirs »

crusty pisze:Ja np. Natknąłem się na takie info o Cisco źródło- uk.businessinsider.com

But it was Juniper's arch rival, Cisco, who took more heat for having products that were allegedly being tampered with so various governments can spy. In 2014, a photo circulated that allegedly showed Cisco devices being intercepted and tampered with by NSA techs. After that, Cisco's Chinese sales tanked, over fears of US government spying.

Cisco's then CEO John Chambers even wrote an open letter to President Obama asking Obama to stop the NSA from hacking into Cisco's equipment.
Tak, ale to nie ma nic wspólnego z problemem, o którym rozmawiamy.

Komentując: to że NSA modyfikowała wysyłany sprzęt - i to nie tylko sprzęt Cisco (JETPLOW), w katalogu NSA znaleźć można też pluskwy do Junipera (FEEDTROUGH) i innych producentów - to jedna sprawa. Producent niewiele tu może zrobić poza zablokowaniem takich implantów za pomocą ochrony sprzętowej - i to też jako pierwsi w świecie ICT robimy od paru lat. Pisałem o tym w innym wątku. Tego na razie nadal nie wdrożył ani Juniper (z tego co mi wiadomo) ani żaden inny duży producent sprzętu sieciowego.

To, że Juniper nie przegląda kodu i dał sobie wstrzyknąć backdoora, a następnie wysyłał go przez lata do klientów - to jednak zupełnie co innego. Oznacza kompromitacje kodu źródłowego i wskazuje na brak procesu code review w firmie, lub - jeszcze gorzej - skompromitowanie tego procesu. Jedno i drugie świadczy bardzo źle, choć hasło zamaskowane było bardzo sprytnie.

Więc ponawiam pytanie - skoro twierdzicie, że Cisco miało problemy w postaci backdoora w IOSie to poproszę o link lub wycofanie się z tego stwierdzenia. I nie, domyślne, udokumentowane hasła się nie liczą, bo to nie backdoor.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#11

#11 Post autor: lbromirs »

A tak BTW:

Cisco przejrzy dodatkowo cały kod źródłowy.

Tak dla pewności. Czy Twój producent sprzętu sieciowego potrafi udokumentować i upublicznić swoje praktyki związane z kontrolą kodu źródłowego? Może warto zapytać?

dorvin
CCIE
CCIE
Posty: 1688
Rejestracja: 21 sty 2008, 13:21
Lokalizacja: Wrocław
Kontakt:

#12

#12 Post autor: dorvin »

W kontekście całego świata IT zastanawia mnie, jaka jest różnica pomiędzy "backdoor" a "vulnerability that allows remote attacker to...". :)

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#13

#13 Post autor: lbromirs »

dorvin pisze:W kontekście całego świata IT zastanawia mnie, jaka jest różnica pomiędzy "backdoor" a "vulnerability that allows remote attacker to...". :)
IMHO oczywista: backdoor to kod osadzony specjalnie aby zapewnic nieautoryzowany dostep. Nie ma znaczenia czy backdoor wsadzil wlasciciel kodu, czy ktos kto mial dostep. Podatnosc dajaca zdalna szanse ataku jest wlasnie tym - dziura (oczywiscie moga byc tez celowe), ktora wykorzystana daje cos lokalnie lub zdalnie.

Backdoor moze udawac podatnosc, ale zwykle wychodzi to na jaw podczas analizy kodu (lub np. jego kontekstu czy daty dodania). Podatnosc daje sie zwykle wylapac w wielu miejscach, jesli byla tylko tym - a nie backdoorem.

Juniper dal sobie wsadzic backdoora i przez wiele lat soft z nim wysylal do klientow. Jak to sie stalo - wyjasnia ich sluzby i kazdy nastepny fundusz rozwazajacy inwestycje w nich. Podatnosci przez ten czas wszyscy (jako producenci) mielismy wiele.

dorvin
CCIE
CCIE
Posty: 1688
Rejestracja: 21 sty 2008, 13:21
Lokalizacja: Wrocław
Kontakt:

#14

#14 Post autor: dorvin »

Sęk w tym, że jeśli backdoora wprowadza celowo właściciel kodu, to spokojnie może go zamaskować jako vulnerability i w razie rozpowszechnienia informacji uruchomić standardowe procedury PR. Nie twierdzę, że wszystkie vulnerability tak powstały, ale moja nabyta paranoja pozwala mi przypuszczać, że takie sytuacje są częstsze, niż sądzimy.

lbromirs
CCIE
CCIE
Posty: 4101
Rejestracja: 30 lis 2006, 08:44

#15

#15 Post autor: lbromirs »

dorvin pisze:Sęk w tym, że jeśli backdoora wprowadza celowo właściciel kodu, to spokojnie może go zamaskować jako vulnerability i w razie rozpowszechnienia informacji uruchomić standardowe procedury PR. Nie twierdzę, że wszystkie vulnerability tak powstały, ale moja nabyta paranoja pozwala mi przypuszczać, że takie sytuacje są częstsze, niż sądzimy.
Tak jak pisałem - takie backdoory dosyć prosto odkrywają bloggerzy, specjalizujący się w reverse engineeringu. Jeśli ktoś robi błąd pozwalający np. na zdalne wejście na roota lub jego odpowiednik, prawdopodobnie ten sam błąd występuje w innych miejscach w kodzie i nie będzie odosobniony. Albo np. powstał w tym samym czasie gdy łatano inne miejsca. Wszystko da się odtworzyć w dużej mierze nawet bez potrzeby dostępu do źródeł. Jeśli taki "błąd" powstaje w odosobnieniu, albo w natłoku innych zmian które nie miały z nim nic do czynienia - automatycznie jest podejrzany. Jest wiele 'triggerów' do dodatkowych review kodu. A potem dziwicie się, że zbudowanie obrazu developmentowego to nie jest 'parę minut' ;)

Cały proces tworzenia bezpiecznego oprogramowania to skomplikowana sprawa i nie twierdzę, że w Cisco opanowaliśmy to do perfekcji. Ale staramy się i co ważniejsze - dużo pokazujemy w ramach w pełni transparentnej komunikacji z Partnerami i Klientami. Jeśli jest zainteresowanie, mogę spróbować ściągnąć kogoś bezpośrednio z developmentu żeby poopowiadał o tym, jak to się u nas robi na jakimś WebExie ("dawaj go" od paru osób wystarczy :P).

Co ciekawe, review kodu nie musi oznaczać tworzenia sztucznych granic i bezsensownych ograniczeń. Np. moje konto w firmie nadal należy do grupy, w której mam dostęp do kodów źródłowych, choć zbudowanie pełnoprawnej binarki jest już trochę bardziej skomplikowane niż odpalenie jednego make'a (ale mamy "za zakładzie" bohaterów, którzy i to przeszli). Oczywiście taka binarka nie ma szans przejść procesu sprawdzania poprawności w trakcie bootu na nowszych urządzeniach, nie tylko dlatego, że nie będzie podpisana cyfrowo.

ODPOWIEDZ