0:14
22/8/2012

Krótko po poważnej wpadce firmy F5, mamy kolejnego producenta sprzętu, który uważa, że trzymanie zapisanych na stałe w firmware kluczy prywatnych to dobry pomysł… Jest nim należąca do Siemensa firma RuggedCom, będąca producentem sprzętu wykorzystywanego w instalacjach typu SCADA. Dzięki Justinowi W. Clarke’owi, który ujawnił klucz prywatny RSA zahardcodowany w Rugged Operating System, każdy może rozszyfrować ruch SSL pomiędzy urządzeniami RuggedCom, a użytkownikiem końcowym.

Iran może się zemścić za Stuxneta?

Ponieważ igranie z systemami SCADA nadzorującymi pracę m.in. elektrowni czy przepompowni wody, a zatem krytycznej infrastruktury, to dość poważna sprawa, ICS-CERT już wydał ostrzeżenie w tej sprawie. Radzi w nim m.in. aby zminimalizować dostęp do internetu urządzeniom działających pod kontrolą systemu ROS (Rugged Operating System). ICS-CERT zwraca także uwagę, że atakujący posiadający klucz może nawiązać złośliwe połączenie z urządzeniem RuggedCom i wymieniać z nim informacje.

pracownicy ruggedcom

Pracownicy RuggedCom – jak myślicie, kto z nich wpadł na pomysł zapisania prywatnego klucza w firmware?

Justin W. Clarke przed publicznym ujawnieniem klucza nie kontaktował się w tej sprawie z producentem. Błędy znalazł analizując kupione z drugiej ręki urządzenia RuggedCom. Dodatkowo wspomina, że ma w zanadrzu kolejne podatności także związane z oprogramowaniem Siemensa. I mimochodem dodaje, że zapewne także ogłosi je światu w ramach full disclosure, bo Siemens znany jest z tego, że niezbyt chętnie odpowiada na informacje o błędach.

Na koniec dodajmy, że to druga podatność jaką Justin W. Clarke znalazł w urządzeniach RuggedCom — w maju ujawnił podatność, która umożliwiała zdalne odczytanie hasła i tym samym dawała atakującemu kontrolę nad urządzeniem.

Czy wpadki F5 i Siemensa wystarczą, aby wybić z głowy przechowywanie kluczy prywatnych w firmware urządzeń?


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

11 komentarzy

Dodaj komentarz
  1. to gdzie się trzyma takie klucze?

    • Na karteczce w sejfie na którym ustawiono szyfr “zniszczenia” (dostęp tylko przez fizyczna detonację sejfu) ;)

    • Znając życie problemem nie jest samo przechowywanie klucza a fakt, że jest on identyczny dla wszystkich urządzeń…Chyba dość dobrym rozwiązaniem by było jakieś bardziej ,,hardware’owe” podejście. Zaszyć gdzieś w urządzeniu układzik, który ma klucz, który jest unikalny i nie będzie nigdy zmieniany itd. To takie moje przemyślenie, które może być błędne, ale przynajmniej na chwilę obecną wydaje się mi sensowne

    • W kliencie Tibii podobnie zrobili i tydzień po ‘update’ już był normalnie klucz dla wszystkich znany. xD

    • marcin – zaszycie unikalnego klucza nie jest bledne. Tak samo jak jednakowego. Problem w tym jak latwo je zdobyc. Sama personalizacja hasel nie rozwiaze sprawy jesli bedzie mozna je wydobyc w latwy sposob. Co nie zmienia faktu ze znaczaco utrudnia juz sam fakt unikalnych hasel.

      Osoby “programujace web” albo nie na urzadzenia wbudowane czesto nie rozumieja potrzeby wyjazdu do serwisowania urzadzenia dajmy na to setki kilometrow by je przywrocic do zycia. I kosztow z tym zwiazanych.

      Przyklad do myslenia: kogo nalezalo by wyslac na marsa zeby otworzyc dostep gdyby ktos zapomnial hasla :) Cusriosity

    • Gimbaza zaczyna odkrywać niebezpiecznik? Logowanie na nieoficjalne serwery odbywało się zwykle poprzez patchnięcie klucza publicznego w binarce na powszechnie znany (co bardzo fajnie niwelowało sens samego zabezpieczenia, ale tibijczyk potrafi), więc generalnie to gadacie głupoty z tym wyciekaniem klucza prywatnego po aktualizacji.

  2. Na pomysł zapisania prywatnego klucza w firmware wpadli ci co mają na zdjęciach ręce w górze. ;-)

  3. Pytanie do tych, którzy twierdzą, że klucze prywatne zapisane na urządzeniach wbudowanych to bezwzględnie samo zło: jak bez klucza prywatnego ma się uruchomić na urządzeniu serwer https lub ssh? :->

    • Na przykład personalizując klucze per-klienta. Jest to o tyle proste, że urządzenia tej klasy nie są dostępne po prostu w sklepach na półkach.

  4. AVE…

    Mam taki program, Window-Eyes, ze sprzętowym kluczem. Całkiem fajna zabawka w sumie. I w sumie nikt nie złamał tego. Nikomu się nie chciało kupić programu za 5k złotych…
    Nie ma różnicy między zaszyciem klucza w sprzęcie lub w oprogramowaniu. Kwestia, jak dobrze ten klucz jest zaszyfrowany i jak napisany jest program go testujący. Można dane zaszyć w mikrokontrolerze, który wymaże je jak tylko obudowa urządzenia zostanie naruszona. Jedna instrukcja w typowym układzie z rodziny PIC1xFxx zabiera 200nS, wymazanie klucza 512-bajtowego zajęłoby około 205 mikrosekund…

  5. […] wpadki z kluczem SSH (którą zaliczyła także firma F5 w loadbalacnerze BigIP oraz Siemens w SCADA), Cisco załatało także 2 inne podatności. Jedna z nich, w webpanelu pozwalała na modyfikowanie […]

Odpowiadasz na komentarz m

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: