Miesiąc: grudzień 2019

Fałszowanie certyfikatów to kolejne zagrożenie. Certyfikaty nie są magiczne; są jedynie udokumentowane kryptograficznie podpisane przez uznany urząd certyfikacji. Techniki kryptograficzne stosowane do podpisywania certyfikatów podlegają atakowi. Wyniki badań wskazujące na ryzyko kolizji MD-5 prowadzących do sfałszowanych certyfikatów zostały pierwotnie opublikowane w 2008 r.38 Z tego powodu wiele organów zaleciło wycofanie certyfikatów podpisanych MD-5. W sierpniu 2011 r. Irańscy internauci zgłosili fałszywy certyfikat podpisany przez MD-5 dla * .google.com

 

W styczniu 2001 r. Firma VeriSign wydała dwa certyfikaty cyfrowe klasy 3 do podpisywania formantów ActiveX i innego kodu osobom podszywającym się pod pracownika Microsoft. W rezultacie użytkownicy otrzymujący kod podpisany przy użyciu tych certyfikatów otrzymaliby prośbę o zaakceptowanie lub odrzucenie certyfikatu najwyraźniej podpisanego przez Microsoft 30 lub 31 stycznia 2001 r. Gdy Russ Cooper skomentował grupę Usenet NTBUGTRAQ, gdy wiadomości pojawiły się w marcu 2001:

Fakt, że jeśli nie sprawdzisz daty na Certyfikacie, nie będziesz wiedział, czy jest to [sic], któremu możesz zaufać, jest Złą Rzeczą ™ [sic], ponieważ oczywiście nie wszyscy (czytaj: obok nikogo) sprawdzi każdy otrzymany certyfikat. Zastanawiasz się, jak mechanizm wydawania VeriSign może być tak źle zaprojektowany i / lub wdrożony, aby pozwolić na coś takiego.

Tymczasem Microsoft [sic] pracuje nad łatką, która wbije palec w tamę. Zasadniczo certyfikaty VeriSign do podpisywania kodu nie wykorzystują funkcji listy odwołania certyfikatów (CRL) o nazwie CDP lub punktu dystrybucji CRL, co powoduje, że certyfikat jest sprawdzany pod kątem odwołania za każdym razem, gdy jest czytany. Nawet jeśli masz włączoną listę CRL w IE, certyfikaty VeriSign do podpisywania kodu nie są sprawdzane. Aktualizacja Microsoftu będzie migać w pewnym mechanizmie, który powoduje, że niektóre / wszystkie certyfikaty podpisujące kod sprawdzają lokalny plik / klucz rejestru pod kątem listy CRL, która (przynajmniej początkowo) będzie zawierać szczegóły tych certyfikatów. Zakładając, że działa to zgodnie z reklamą, każda próba zaufania do źle wydanych certyfikatów powinna zakończyć się niepowodzeniem.

Roger Thompson, dyrektor ds. Technicznych w Laboratoriach zapobiegania wykorzystywaniu luk, wyjaśnił, że motywy oszustów określają, jak złe byłyby wyniki fałszywych certyfikatów. „Jeśli był to ktoś, kto miał jakiś cel, to sześć tygodni to dużo czasu, aby coś zrobić” – powiedział. „Jeśli zadaniem było zainstalowanie sniffera, to mogło być w rezultacie zillionem backdoorów. ”Opublikowane raporty wskazują, że niepowodzenie uwierzytelnienia nastąpiło z powodu błędu w procesie wydawania w VeriSign: Certyfikaty zostały wydane przed otrzymaniem wiadomości e-mail z potwierdzeniem, że oficjalny kontakt z klientem autoryzował certyfikaty. Ta sprawa była pierwszą wykrytą awarią uwierzytelnienia w ponad 500 000 certyfikatów wydanych przez VeriSign. Niektóre ostatnie przypadki dotyczące skradzionych lub sfałszowanych certyfikatów obejmują:

* W listopadzie 2011 r. Sprzedawca oprogramowania antymalware Mikko Hypponen, firma F-Secure, poinformował, że „znalazł kawałek złośliwego oprogramowania, które zostało kryptograficznie podpisane fałszywym certyfikatem Adobe pochodzącym z rządu Malezji: malezyjski instytut badań i rozwoju rolnictwa…”

* We wrześniu 2012 r. Adobe poinformowało, że „… otrzymały dwa złośliwe narzędzia, które wyglądały na podpisane cyfrowo przy użyciu ważnego certyfikatu do podpisywania kodu Adobe”. Firma wyjaśniła: „Wyrafinowani aktorzy zagrożeń używają złośliwych narzędzi, takich jak podpisane próbki, podczas wysoce ukierunkowanych ataków uprzywilejowanie eskalacji i bocznego przemieszczania się w środowisku po początkowym naruszeniu bezpieczeństwa komputera. ”

* W lutym 2013 r. Bit9 Systems ujawnił, że „Ze względu na nadzór operacyjny nad Bit9 nie udało nam się zainstalować własnego produktu na kilku komputerach w naszej sieci. W rezultacie złośliwa strona trzecia mogła nielegalnie uzyskać tymczasowy dostęp do jednego z naszych certyfikatów do cyfrowego podpisywania kodu, którego następnie użyła do nielegalnego podpisania złośliwego oprogramowania. Nic nie wskazuje na to, że był to problem z naszym produktem. Nasze dochodzenie pokazuje również, że nasz produkt nie został naruszony. ”

27 stycznia 1997 r. Niemiecki program telewizyjny pokazał demonstrację członków Chaos Computer Club ,w jaki sposób mogliby użyć formantu ActiveX do kradzieży pieniędzy z konta bankowego. Kontrola, dostępna w Internecie, została napisana w celu obalenia popularnego pakietu księgowego Quicken za pomocą elektronicznej wersji tailgating. Ofiara musi jedynie odwiedzić witrynę i pobrać kontrolkę ActiveX, o której mowa; formant następnie automatycznie sprawdza, czy zainstalowano Quicken. Jeśli tak, kontrola nakazała Quicken wystawić zlecenie przeniesienia, które zostanie zapisane na liście oczekujących przelewów. Następnym razem, gdy ofiara połączy się z odpowiednim bankiem i wyśle ​​do banku wszystkie oczekujące polecenia przelewu, wszystkie przelewy zostaną wykonane jako jedna transakcja. Osobisty numer identyfikacyjny użytkownika (PIN) i numer autoryzacji transakcji (TAN) będą miały zastosowanie do wszystkich przelewów, w tym oszukańczych w stosie zamówień. Większość ofiar byłaby nieświadoma kradzieży, dopóki nie otrzyma kolejnego zeznania – jeśli wtedy. Dan Wallach z Princeton University, komentując tę ​​sprawę, napisał:

Gdy akceptujesz kontrolkę ActiveX, zezwalasz na to, aby całkowicie dowolny kod szperał w twoim komputerze i robił wszystko, co mu się podoba. Ten sam kod może wykonywać niezwykle kosztowne rozmowy telefoniczne na numery 900 lub na duże odległości za pomocą modemu; potrafi czytać, zapisywać i usuwać dowolny plik na twoim komputerze; potrafi instalować konie trojańskie i wirusy. Wszystko bez podstępu i hakerów wymaganych do zrobienia tego w Javie. ActiveX przekazuje klucze do komputera. Odpowiadając na krytykę modelu bezpieczeństwa ActiveX, Bob Atkinson, architekt i główny implementator Authenticode, napisał długi esej wyjaśniający jego punkt widzenia. Wśród kluczowych punktów:

* Microsoft nigdy nie twierdził, że poświadcza bezpieczeństwo kodu innych osób.

* Uwierzytelnianie ma na celu wyłącznie identyfikację sprawców po wykryciu złośliwego kodu.

* Dystrybucja oprogramowania oparta na eksploratorze nie jest bardziej ryzykowna niż konwencjonalne zakupy przez sprzedawców oprogramowania.

Późniejsza korespondencja na forum RISKS karała pana Atkinsona za pominięcie kilku innych kluczowych punktów, takich jak:

* Interakcje między kontrolkami ActiveX mogą naruszać bezpieczeństwo systemu, nawet jeśli poszczególne kontrolki wydają się nieszkodliwe.

* W rzeczywistości nie ma precedensu w zakresie kładzenia odpowiedzialności u twórców oprogramowania, nawet jeśli można je znaleźć.

* Pod atakiem dowód podpisu cyfrowego prawdopodobnie wyparuje z uszkodzonego systemu.

* Opóźnienie wykonania szkodliwych ładunków skomplikuje identyfikację źródła uszkodzenia.

* Złośliwość nie jest tak ważnym zagrożeniem ze strony kodu jak niekompetencja.

* Firma Microsoft ma w historii opcje zagrażające bezpieczeństwu, takie jak automatyczne wykonywanie makr w programie Word, bez oferowania jakiegokolwiek sposobu wyłączenia tej funkcji.

* Witryna AWeb może wywoływać formant ActiveX, który znajduje się w innej witrynie lub który został już pobrany z innej witryny, i może przekazywać za pomocą tej kontroli nieoczekiwane argumenty, które mogą wyrządzić szkodę.

Krytyka Wallacha dotycząca ActiveX ma ogólne zastosowanie do technologii podpisanego kodu, a nie jest specyficzna dla ActiveX Microsoftu.

Od czasu wprowadzenia tej technologii w połowie lat 90. miało miejsce kilka naruszeń bezpieczeństwa lub demonstracje, w których pośredniczy ActiveX.

Internet Exploder.

W 1996 roku Fred McLain napisał Internet Exploder, kontrolkę ActiveX zaprojektowaną w celu zilustrowania szerokiego stopnia zaufania do kontroli ActiveX z racji jej podpisania. Exploder, po pobraniu do wykonania przez Internet Explorera, zamknie komputer przeglądarki (odpowiednik sekwencji Shutdown | Shutdown z menu Start w systemie Windows). Ta operacja jest zakłócająca działanie, ale tak naprawdę nie uszkadza systemu. McLain zauważa w swoich często zadawanych pytaniach na temat programu Exploder, że łatwo jest tworzyć destrukcyjne lub złośliwe elementy sterujące. Exploder podnosi ważne pytanie: kto i jakie są ograniczenia zaufania przy użyciu podpisanego kodu? W normalnych sprawach handlowych istnieje duża różnica między nieautentycznym podpisem, fałszerstwem a prawidłowo podpisanym, ale nieopłacalnym czekiem. W oprogramowaniu różnica między nieautentyczną kontrolą a niebezpieczną jest znacznie mniej wyraźna.

Warsztaty CERT / CC na temat bezpieczeństwa w ActiveX podsumowały kwestie bezpieczeństwa w trzech głównych obszarach: importowanie i instalowanie kontrolek, uruchamianie kontrolek oraz korzystanie z kontroli przez skrypty. Kluczowe wnioski z tego raportu są następujące:

* Importowanie i instalowanie elementów sterujących

-Jak omówiono, jedyną podstawą zaufania do podpisanej kontroli jest jej przypuszczalne pochodzenie. Jednak twórca kodu mógł mieć wadę projektową w kontroli lub może nie zapewnić odpowiedniej jakości oprogramowania, aby zapobiec poważnym błędom.

– Ufający użytkownik może zainstalować podpisaną kontrolkę, która zawiera lukę, dzięki czemu jest przydatna dla atakujących tylko dlatego, że jest podpisana.

– W systemach OnWindows z wieloma użytkownikami, gdy kontrola zostanie dozwolona przez jednego użytkownika, pozostaje dostępna dla wszystkich użytkowników, nawet jeśli ich poziomy bezpieczeństwa są różne.

* Kontrola działania

– Formant ActiveX nie ma ograniczeń co do tego, co może zrobić na komputerze klienckim i działa z tymi samymi uprawnieniami, co uprawnienia użytkownika, który zainicjował kontrolę.

– Chociaż środki bezpieczeństwa ActiveX są dostępne w Internet Explorerze, inne oprogramowanie klienckie może uruchamiać kontrole bez koniecznej implementacji takich zabezpieczeń. Poziomy zabezpieczeń przeglądarki Internet Explorer są zwykle zerowe lub całkowite, co utrudnia dopuszczenie określonej kontroli bez dopuszczenia wszystkich kontroli tego typu. Zdalna aktywacja kontroli może ominąć normalne obwody bezpieczeństwa, takie jak narzucone przez zapory ogniowe.

– Nie ma podstaw do podjęcia decyzji, czy dana kontrola jest bezpieczna do wykonania, czy nie, w jakimkolwiek określonym kontekście.

* Obawy związane ze skryptami

– Brak ogólnej podstawy do ograniczenia działań kontrolnych, programiści ActiveX muszą skutecznie określić własne środki ostrożności, aby zapobiec szkodliwym działaniom. Wystarczająco trudno jest opracować dobry zestaw granic działania programu, nawet jeśli używa się ogólnego modelu, takiego jak piaskownica opisana później; niezwykle trudno jest zobaczyć, w jaki sposób można oczekiwać od poszczególnych programistów lub, co ważniejsze, zaufać, że utworzą własny odpowiednik piaskownicy dla każdej kontroli. W świetle tych zagrożeń autorzy raportu CERT / CC stwierdzili, że „istnieje duża liczba potencjalnych punktów awarii”.

Technologie podpisywania, niezależnie od kontekstu (np. E-mail, aplety i archiwa), nie odpowiadają bezpośrednio na pytania dotyczące dokładności lub poprawności; odnoszą się jedynie do kwestii pochodzenia. Największym niebezpieczeństwem związanym z podpisywaniem programów jest podejście polegające na zaufaniu „wszystko albo nic”. Podpisane elementy uznaje się za godne zaufania w pełnym zakresie uprawnień użytkownika proszącego. Podpisany element może wykonać dowolną operację, którą użytkownik może wykonać. Nie ma pojęcia częściowego zaufania. Według słów pełnomocnika taka akceptacja byłaby ogólnym pełnomocnictwem. Zgodnie ze słowami bezpieczeństwa sponsorowanego przez CERT / Centrum Koordynacji (CERT / CC) w warsztacie ActiveX: „Podpis cyfrowy nie daje jednak żadnej gwarancji dobroci ani kompetencji.” Jednocześnie wrodzona moc i widoczna legalność podpisu cyfrowego stanowi duże obciążenie dla sygnatariuszy i wyższych poziomów infrastruktury PKI, aby zapewnić integralność mechanizmów i tajemnic. Kluczem do integralności podpisanego kodu jest proces podpisywania i proces generujący obiekt do podpisania; bezpieczeństwo tajnych kluczy wymaganych do jego wdrożenia określa stopień zaufania w zakresie przypisywania podpisanego kodu. W najprawdziwszym sensie klucze prywatne powiązane z certyfikatem X.509 reprezentują klucze do królestwa, tak cenne jak podpis na Dalekim Wschodzie lub faksowa tablica podpisu na konto bankowe. Na poziomie praktycznym akceptacja kodu podpisanego przez organizację jest wyraźną akceptacją tego, że organizacja podpisująca ma dobrą kontrolę nad użyciem swoich kluczy podpisu. Organizacje, które poważnie podchodzą do kwestii bezpieczeństwa, segregują dostęp do uprzywilejowanych kont i kontrolują dostęp do systemów, są dobrze przygotowane do zarządzania procedurami podpisywania kodu. W związku z tym procedury i systemy stosowane do podpisywania kodu należy traktować z taką samą ostrożnością, jak w przypadku wyżej wymienionych tablic podpisujących lub urządzeń kryptograficznych o maksymalnym bezpieczeństwie znanych osobom z obszaru bezpieczeństwa narodowego. Niestety, pomimo wielu lat rozgłosu na temat zagrożeń związanych ze wspólnymi hasłami i kontami, wiele instalacji IT nadal korzysta ze wspólnych kont i haseł. Nie ma powodu, by zakładać, że tajemnice związane z PKI są lepiej chronione, pomimo obszernych zaleceń, aby te szczegóły były dobrze strzeżone.

Technologia Authenticode firmy Microsoft jest przykładem podejścia opartego na uwierzytelnianiu. 25 Programiści, którzy chcą rozpowszechniać kod, otrzymują odpowiedni certyfikat cyfrowy od urzędu certyfikacji i używają certyfikatu cyfrowego do podpisania kodu. Podpis jest następnie sprawdzany przez system klienta za każdym razem, gdy kod jest wykonywany. Authenticode opiera się na kilku komponentach:

* Certyfikaty PKI i X.509 wydane przez urząd certyfikacji.

* Ograniczony dostęp do kluczy prywatnych związanych z certyfikatem X.509 organizacji wydającej. W terminologii Microsoft termin Software Publishing Certificate lub SPC odnosi się do obiektu PKCS # 7, który z kolei zawiera zbiór certyfikatów X.509 używanych do podpisywania kodu.

* Integralność procesów używanych przez urząd certyfikacji w celu zapewnienia, że ​​żądania certyfikatów X.509 są prawidłowe.

Authenticode nie rozwiązuje problemów związanych z bezpieczeństwem lub dokładnością podpisanego kodu, a jedynie to, że jest autentyczny i niezmieniony od momentu podpisania. Na przykład podpisywanie nie chroni przed przypadkami złego traktowania pracowników.

Technologie uwierzytelniania mają na celu zapewnienie, że informacje dostarczone przez organizację nie zostaną zmienione bez autoryzacji. Technologia zastosowana do wdrożenia tego zapewnienia opiera się na wykorzystaniu infrastruktury klucza publicznego (PKI). Kod uwierzytelniany przy użyciu mechanizmów opartych na PKI często jest nazywany podpisem. Podpisany kod jest zasadniczo odporny na nieautoryzowane uwierzytelnianie; jednak podpis gwarantuje integralność tylko od momentu podpisania kodu; proces podpisywania nie oznacza bezpieczeństwa ani jakości kodu przed momentem podpisania. Po podpisaniu pliku nie można zmienić bez unieważnienia oryginalnego podpisu; bez współpracy osoby mającej dostęp do klucza prywatnego powiązanego z certyfikatem organizacji X.509 organizacji, podpisu nie można realistycznie zmodyfikować, aby wyglądał na zgodny z prawem. (Certyfikat X.509, podpisany cyfrowo przez autoryzowanego użytkownika, uwierzytelnia powiązanie między nazwą użytkownika a kluczem publicznym użytkownika.) Jednak patrząc pod powierzchnią, takie środki ostrożności nie uwzględniają różnych luk w zabezpieczeniach:

* Nieautoryzowany dostęp do kluczy prywatnych (podpisywanie)

* Dostęp do bazy kodu przed podpisaniem

* Fałszywe certyfikaty

* Błędy projektowe i implementacyjne

Błędy projektowe i implementacyjne przyjmują różne formy. Najprostsze przypadki dotyczą oprogramowania, które działa w sposób ciągły i przewidywalny. Bardziej szkodliwe i bardziej niebezpieczne są te błędy, które dyskretnie zagrażają ścisłemu ograniczeniu środowiska wielu użytkowników. Błędy w takich warstwach profilaktycznych, znane jako ceglane ściany lub piaskownice, zagrażają integralności schematu ochrony. W najgorszych przypadkach umożliwiają nieograniczony dostęp do zasobów na poziomie systemu przez nieuprzywilejowane programy użytkownika. Błędy projektowe i implementacyjne mogą wystąpić w dowolnym programie lub procedurze, a kod mobilny nie jest wyjątkiem. Piaskownice (nieuprzywilejowane, ograniczone środowiska operacyjne) mają na celu zapobieganie nieautoryzowanym operacjom. Uwierzytelnianie określa, która organizacja bierze odpowiedzialność za takie błędy. W tej części omówiono model bezpieczeństwa oparty na uwierzytelnianiu kodu mobilnego, a następnie zbadano, w jaki sposób ograniczone środowiska operacyjne pomagają ograniczyć szkody spowodowane szkodliwym kodem mobilnym. Obawy te dotyczą zarówno szeroko rozpowszechnionych, jak i ukierunkowanych ataków. Wyzwanie ataków ukierunkowanych leży w ich małej populacji; ukierunkowane ataki raczej nie pojawią się na radarze ogólnych programów skanujących dystrybucję.

Motywacje i cele twórców szkodliwego oprogramowania kontynuowały ewolucyjny trend, od mimowolnie niszczącego do mściwego, mściwego i kryminalnego. Nic dziwnego, że aktorzy migrowali z nieuczciwych indywidualnych dowcipnisiów do przestępców oraz państw narodowych i pełnomocników. Na początku wiele incydentów było losowo szkodliwych lub psikusów z niezamierzonymi skutkami ubocznymi. Tak już nie jest. Teraz złośliwy kod mobilny jest często kodem przeznaczonym do tego celu. Ten cel może być zawstydzeniem, szantażem, szpiegostwem korporacyjnym lub kradzieżą. W innym wymiarze celem może być podporządkowanie skądinąd niewinnych zasobów komputerowych przedsiębiorstwu przestępczemu przeciwko niepowiązanym stronom trzecim. Zmiana celów ma również dramatyczny wpływ na strategie przeciwdziałania. Kiedy celem była masowa reklama, ta sama infekcja była szeroko rozpowszechniona, a technologie skanowania można było wykorzystać do identyfikacji znanych zagrożeń. Kiedy celem nie jest już rozgłos, rozgłos i powszechna infekcja są nieprzystosowalne. Ukryta infekcja jest wówczas znacznie bardziej atrakcyjną strategią niż dystrybucja masowa. Nie jest prawdopodobne, aby niestandardowy kod mobilny zaprojektowany w celu osiągnięcia selektywnych tajnych infekcji szybko pojawiał się na celowniku oprogramowania do skanowania. Jest to zgodne z trajektorią ewolucji powszechną w świecie biologicznym, w której patogeny z czasem mutują się w mniej śmiertelne formy. Jest nieprzystosowalny do pasożyta, którym jest większość złośliwego oprogramowania, aby śmiertelnie uszkodzić swojego gospodarza. Minusem tego efektu jest to, że przewlekłe infekcje bez widocznych skutków ubocznych są często pomijane. W przyszłości technologie i procedury operacyjne, które utrudniają nieautoryzowanemu kodowi zamieszkiwanie w trwałym stanie systemu lub narażanie go na szwank, są znacznie bardziej pożądanymi strategiami przeciwnymi niż podejścia oparte na skanowaniu w poszukiwaniu znanych infekcji.