18-03-2019 / Podcast

Jak zniszczyć reputację firmy?

Wprowadzenie

Cześć!

Ja jestem Kacper Szurek a to 35 odcinek Podcastu Szurkogadanie.

W tym tygodniu przygotowałem 9 informacji powiązanych z bezpieczeństwem komputerowym.

Jak zniszczyć reputację firmy przy pomocy funkcji wiki na GitHubie.

Dlaczego menadżery haseł to skomplikowany kawałek technologii - o prawidłowym rozpoznawaniu subdomen.

Jak złośliwy serwer MySQL może pobrać dane od klienta.

Co jest powodem rozpowszechniania złośliwego oprogramowania w sieci torrent?

O meandrach języka PHP - jak to możliwe że fałsz to prawda.

A na koniec jak działają ataki czasowe.

Podcast ten można również znaleźć na Spotify oraz Google i Apple Podcasts oraz Anchor.

Większość informacji do tego odcinka odnalazłem dzięki Weekendowej Lekturze Zaufanej Trzeciej Strony.

Jeżeli ten materiał Ci się spodobał rozważ zostawienie gwiazdki i recenzji w aplikacji Apple podcast.

Więcej informacji na temat bezpieczeństwa znajdziesz na naszej grupie od 0 do pentestera na Facebooku.

Zapraszam do słuchania

Atak na firmę przy pomocy wiki na GitHub

 Atak na firmę przy pomocy wiki na GitHub

Git to system kontroli wersji.

To dzięki temu narzędziu wielu programistów może pracować nad tym samym projektem, widząc wprowadzane przez siebie zmiany.

GitHub to popularna platforma, która pozwala na hostowanie plików gita.

Ale serwis ten posiada również dodatkowe funkcjonalności.

Jedną z nich jest możliwość tworzenia stron wiki.

Idea tego rodzaju podstron została zaczerpnięta z Wikipedii.

Można je wykorzystać do przetrzymywania dokumentacji, chociażby aby zademonstrować jakie kroki należy podjąć aby zainstalować daną aplikację.

Ale ze stronami wiki wiąże się ciekawostka.

GitHub pozwala bowiem na tworzenie tak zwanych prywatnych repozytoriów.

Wtedy dostęp do kodu jest ograniczony - to znaczy mogą go widzieć i edytować jedynie osoby i organizacje, którym udzielimy odpowiedniego dostępu.

Ale czasami zdarza się, że po pewnym czasie chcemy wypuścić nasz projekt w świat.

Wtedy to wystarczy zmienić widoczność projektu z prywatnego na publiczny i nasz kod będzie dostępny dla wszystkich.

Tylko, że tym samym zmienią się również ustawienia powiązane ze stronami wiki.

W standardowej konfiguracji bowiem - takie strony może edytować każdy, zalogowany użytkownik GitHuba.

A najczęściej nie jest to coś na co chcemy pozwolić.

Wyobraźmy sobie bowiem, że jesteśmy dużą firmą tworzącą oprogramowanie i nagle udostępniamy jeden z naszych projektów na zasadach open source.

Po chwili na naszej wikipedii powiązanej z tym projektem pojawiają się erotyczne zdjęcia i niewybredne komentarze.

Co więcej, zazwyczaj nie będziemy świadomi takiej zmiany - a to dlatego, że standardowo serwis nie wysyła żadnych powiadomień na temat tego rodzaju zmian.

Oczywiście zdjęcia to tylko przykład.

Równie dobrze atakujący może zmodyfikować dokumentację tak, aby wykorzystać ja do ataków phishingowych - przekonując niczego nieświadomych użytkowników do instalacji złośliwego oprogramowania.

Dlatego też aby ustrzec się przed tego rodzaju wypadkami należy w każdym repozytorium zaznaczyć opcję, w której definiujemy, że tylko użytkownicy z uprawnieniami współpracownika mogą edytować daną treść.

Na nieszczęście dla administratorów firmowych kont, nie istnieje jeden, główny przełącznik per konto.

Każde z repozytorium musi mieć tą opcję zaznaczoną indywidualnie.

Złośliwy serwer MySQL

 Złośliwy serwer MySQL

MySQL to baza danych, która posiada pewną mało znaną funkcję, która może zostać nadużyta w ciekawy sposób.

Z bazą danych można się połączyć przy pomocy klienta.

Wtedy to możliwe jest wysyłanie komend do serwera.

Jedną z takich komend jest "LOAD DATA LOCAL INFILE".

Pozwala ona na wysłanie do bazy pliku w formacie CSV, na którego podstawie tworzona jest nowa tabela.

Cała operacja wygląda mniej więcej tak:

Klient wysyła komendę do serwera, w której to podaje nazwę pliku a także nazwę wynikowej tabeli.

Gdy użytkownik posiada odpowiednie uprawnienia, serwer odpowiada prosząc klienta o podanie treści pliku.

W odpowiedzi klient zwraca plik, którego żąda serwer.

Takie jest standardowe działanie tej komendy.

To znaczy serwer prosi o plik, którego nazwa została wcześniej przesłana przez klienta.

Ale co w przypadku, gdy klient łączy się ze złośliwym serwerem, który nie do końca trzyma się tej procedury?

Serwer może wtedy poprosić o dowolny plik, niekoniecznie ten wcześniej podany przez użytkownika.

A co najciekawsze, klient mu ten plik zwróci - o ile oczywiście takowy obiekt istnieje w danym systemie.

Ta funkcjonalność została wykorzystana do stworzenia honeypota.

Honeypot to serwer, który symuluje działanie jakiegoś protokołu w naszym wypadku mysql.

Jego głównym zadaniem jest wczesne rozpoznawanie zagrożeń.

W Internecie bowiem trwają nieustanne ataki.

Wiele osób przeszukuje całą sieć w poszukiwaniu niezabezpieczonych serwerów, próbując się do nich włamać i wykraść dane.

To samo tyczy się serwerów mysql.

Jeżeli przez przypadek albo błędną konfigurację udostępniony zostanie taki serwer i możliwy będzie do niego dostęp z zewnątrz - istnieje spora szansa, że prędzej czy później dojdzie do włamania.

Cały koń trojański dla atakujących działa zatem następująco:

Honeypot nasłuchuje na porcie 3306 akceptując każdy login i hasło jako prawidłowy.

Atakujący łączy się z takowym serwerem.

W tym momencie serwer czeka, aż przesłana zostanie komenda LOAD DATA.

Wtedy to podmienia nazwę pliku na /etc/shadow - czyli plik, w którym znajdują się hasła użytkowników.

Jeżeli atakujący prześle ten plik, nasz serwer sprawdza czy możliwy jest dostęp po SSH.

W przypadku twierdzącej odpowiedzi, przystępujemy do łamania haseł przy pomocy ataku słownikowego.

Jeżeli ustawione hasło było słabe - możliwe jest zalogowanie się na serwer atakującego.

Tak to atakujący staje się ofiarą a to wszystko przy pomocy mało znanej funkcjonalności.

Wychodzi zatem na to, że łączenie się przy pomocy klienta z zewnętrznymi, niekontrolowanymi przez nas serwerami mysql nie jest takie bezpieczne jak mogło by się wydawać.

A wszystko przez to, że klient ufa komendom przesyłanym przez serwer.

Czy warto korzystać z autouzupełniania?

 Czy warto korzystać z autouzupełniania?

Używanie menadżerów haseł w dzisiejszych czasach to konieczność.

Ciężko mi sobie bowiem wyobrazić, że każdy z nas jest w stanie zapamiętać dziesiątki losowych i skomplikowanych haseł do różnych serwisów internetowych.

A myślę, że nikogo nie trzeba przekonywać jak ważne jest posiadanie różnych haseł do różnych witryn.

Zwłaszcza w dzisiejszych czasach, kiedy to praktycznie co miesiąc dowiadujemy się o różnorakich wyciekach danych.

Ale stworzenie nowego menadżera haseł nie jest takie proste, pomimo iż idea wydaje się być nieskomplikowana.

Na każdym kroku bowiem na programistów czekają różne niespodzianki.

Weźmy chociażby funkcjonalność auto uzupełniania.

To dzięki niej wchodząc na konkretną stronę, pole z loginem i hasłem jest automatycznie wypełniane przez menadżer.

Dzięki temu nie musimy go ręcznie kopiować i wklejać a wystarczy jedynie kliknąć w guzik zaloguj.

Jest to bardzo fajne rozwiązanie z punktu użyteczności ale co z bezpieczeństwem?

Jak bowiem taka funkcja działa pod spodem?

Narzędzie musi pobrać adres strony na której jest obecnie użytkownik, a następnie porównać je z listą witryn zapisanych w swojej bazie.

Jeżeli znajdzie trafienie, musi następnie przeprocesować kod HTML w poszukiwaniu odpowiedniego pola a następnie wypełnić go zapisanymi danymi.

Tylko, że porównywanie domen to nie taka prosta sprawa.

Musimy tutaj bowiem wziąć pod uwagę subdomeny.

Czy bowiem witryna a.google.com to to samo co b.google.com?

Sprawa robi się tym bardziej skomplikowana, jeżeli weźmiemy pod uwagę serwisy umożliwiające swoim klientom na korzystanie z tej samej domeny.

Wyobraźmy sobie bowiem platformę sprzedażową, w której każdy z nas może utworzyć nowy sklep.

Jest on momentalnie dostępny pod adresem naszsklep.stronazesklepami.local

Jak taką domenę będzie traktował nasz menadżer?

Czy wypełni nasz login i hasło tylko na subdomenie naszsklep a może także na każdej innej w obrębie stronazesklepami.local

W tym drugim wypadku - jest to niebezpieczne, ponieważ w taki sposób może dojść do wycieku danych.

Wystarczy bowiem, że atakujący założy sklep pod nazwą atakujący.stronazesklemami.local a następnie prześle nam link do takowego sklepu.

Jeżeli menadżer haseł, nieodpowiednio obsługuje subdomeny i traktuje wszystkie jako takie same, automatycznie uzupełni nasz login i hasło w polu kontrolowanym przez witrynę atakującego.

W momencie pojawienia się hasła w polu tekstowym, atakujący przy pomocy kawałka kodu JavaScript może wysłać te dane na swój serwer.

I to wszystko bez naszej interakcji.

Dlatego też jeżeli jesteś właśnie w trakcie tworzenia własnego rozwiązania do przechowywania haseł może Cię zainteresować projekt https://publicsuffix.org

Zawiera on listę wszystkich suffixów, czyli domen, które pozwalaja na rejestracje subdomen.

Rozpatrując to na przykładzie, w Polsce możemy kupić domenę w obrębie domeny regionalnej.

Chociażby naszanazwa.krakow.pl czy też nazwanazwa.warszawa.pl

Lista ta może pozwolić na lepsze zarządzanie subdomenami.

Czy zatem warto korzystać z autouzupełniania?

Co o tym sądzicie?

Dajcie znać w komentarzach.

Czy warto używać mechanizmu authenticode?

 Czy warto używać mechanizmu authenticode?

Autor Notepad++ opublikował niedawno oświadczenie, w którym zapowiedział, że nowe wersję tego popularnego edytora tekstu nie będą podpisywane przy pomocy mechanizmu authenticode.

Co to oznacza dla normalnych użytkowników Windowsa?

W tej platformie każdy plik wykonywalny - czyli ten z rozszerzeniem .exe może być przez twórcę podpisany odpowiednim certyfikatem.

Certyfikat taki wydają odpowiednie instytucje za odpowiednią opłatą.

One to mają za zadanie odpowiednio sprawdzić naszą tożsamość - upewniając się, że my to my - czyli czy posiadamy prawa do nazwy, którą chcielibyśmy podpisywać pliki.

Chodzi bowiem o to, aby uniknąć sytuacji w której losowa osoba mogłaby podpisywać pliki jako Microsoft.

Autor uzasadnia swoją decyzję tym, iż certyfikaty są względnie drogie.

Dodatkowo, nie mógłby on podpisywać swoich plików jako Notepad++ - ponieważ nie posiada on zarejestrowanej działalności gospodarczej pod takową nazwą.

Firmy certyfikacyjne zatem nie są w stanie zweryfikować czy dany podmiot posiada uprawnienia do posługiwania się taką nazwą.

Dla użytkowników końcowych oznacza to żółte okienko z informacją: "Czy chcesz zezwolić tej aplikacji pochodzącej od nieznanego wydawcy na wprowadzenie zmian na tym urządzeniu?" podczas instalacji oprogramowania.

Jak zatem sprawdzić, czy pobrany przez nas instalator jest prawdziwym instalatorem Notepad++?

Autor programu zaleca sprawdzanie hashy sha256 dostępnych na podstronie z instalatorem.

Jeżeli wszystko się zgadza - oznacza to, że oprogramowanie po drodze nie zostało zmodyfikowane przez żadne zewnętrzne podmioty i zostało wydane przez samego autora.

Ale czy aby na pewno?

W komentarzach na reddicie wywiązała się ciekawa dyskusja na ten sam temat.

Mowa tam o jednym, specyficznym problemie, którego nie wzięto tutaj pod uwagę.

Jeżeli bowiem ktoś byłby w stanie podmienić instalator na oficjalniej stronie rozwiązania nic nie stoi na przeszkodzie aby podmienił również hashe sha256, które się tam znajdują.

W takim wypadku - potencjalny użytkownik, pomimo dochowania wszelkiej staranności i sprawdzenia pliku przed uruchomieniem, mógłby zostać zainfekowany potencjalnie złośliwym oprogramowaniem.

W przypadku podpisanych plików takie ryzyko jest nieco mniejsze.

Dlaczego? Obecnie bowiem większość certyfikatów nie jest już dystrybuowana w formie plików a w formie fizycznej karty kryptograficznej.

Podpis jest tam przechowywany w bezpieczny sposób i bardzo trudne jest wydobycie takiego podpisu z takiej karty.

Autor podczas tworzenia instalatora, musi tylko na kilka minut podpiąć taką kartę do czytnika podłączonego do komputera a następnie podać swój kod pin, służący do odblokowania rozwiązania.

Następnie następuje podpisanie pliku, a karta może zostać schowana chociażby do portfela.

Jak widać - w takim rozwiązaniu - okienko czasowe, w którym atakujący mógłby nadużyć certyfikatu jest dużo krótsze.

Czy zatem nie istnieją inne, tańsze rozwiązania?

Inni komentujący przekonują do używania GPG, który również może służyć do podpisywania plików.

Tutaj jednak ponownie jak w przypadku dystrybucji hashy - użytkownik chcący sprawdzić poprawność podpisu musi najpierw pobrać klucz publiczny podpisującego.

Lista takich prawidłowych kluczy nie jest bowiem dostępna w standardowej instalacji Windowsa.

Dodatkowo, osobno należy pobrać oprogramowanie służące do weryfikacji podpisów - ponieważ one również nie są w standardzie wspierane przez system operacyjny.

Inna możliwością jest publikowanie haszy w kilku miejscach - czyli oprócz strony, publikacja tych samych haszy na GitHubie i innych portalach.

Ale sprawdzanie haszy w kilku miejscach jest uciążliwe z punktu widzenia użytkowników.

Czy zatem podjęta przez autora decyzja jest prawidłowa?

Czy na świecie nie znalazła się żadna firma, która byłaby w stanie zafundować autorowi taki certyfikat za darmo?

Wszak Notepad++ jest używany przez spore grono użytkowników.

Malware a programy partnerskie

 Malware a programy partnerskie

Dla twórców złośliwego oprogramowania samo stworzenie narzędzia to dopiero połowa sukcesu.

Należy je jeszcze odpowiednio rozdystrybuować - czyli sprawić, aby pojawiło się na komputerze użytkowników.

Oczywiście można wykorzystywać różnego rodzaju podatności i błędy w przeglądarkach i systemach operacyjnych.

Ale takie ataki nie są zbyt częste.

Znacznie prostsze i bardziej efektywne jest przekonanie użytkownika do uruchomienia danego pliku.

Ale jak kogoś przekonać do wykonania takiej akcji?

Wszystko zależy od grupy docelowej.

Może istnieje grono osób, które często uruchamia pobrane z Internetu pliki wykonywalne?

O kim mowa? O osobach, które ściągają nielegalne wersje programów i gier.

Takie to osoby przeszukują różne fora i witryny w poszukiwaniu danych, które je interesują.

Można do tego celu używać również protokołu torrent - czyli metody dystrybucji plików, w której to nie ściąga się danych z jednego, głównego serwera, ale od różnych osób, które akurat posiadają dany zasób.

Aby rozpocząć przygodę z tym formatem, należy jednak posiadać plik torrent, w którym to zdefiniowane są niezbędne informacje, takie jak zawartość archiwum czy też sumy kontrolne plików.

Istnieje wiele stron, które udostępniają takie pliki.

Istnieją one na pograniczu prawa - wszak sam meta plik to nie dane chronione prawami autorskimi, a sama treść nie jest przechowywana na tych witrynach ale przez samych użytkowników.

Tak więc działa ten proceder udostępniania nielegalnych plików pomiędzy wieloma użytkownikami.

Zdają sobie z tego sprawę przestępcy, którzy postanowili nadużyć ten mechanizm.

Na stronach trackerów, udostępniają pliki podszywające się pod popularne oprogramowanie i filmy.

Po ściągnięciu takiego materiału i jego uruchomieniu, użytkownik proszony jest o podanie loginu i hasła do serwisu.

W ten sposób twórcy malware’u, mogą rozpowszechniać swoje oprogramowanie dalej korzystając z czyjegoś konta.

Dla większości użytkowników bowiem, konta, które zostały założone kilka dni temu nie są zbyt wiarygodne.

Co innego jednak, gdy materiał opublikuje osoba z wieloletnim stażem.

Ale to nie wszystko.

Następnie taki złośliwy plik uruchamia tak zwany clicker.

Jest to program, którego głównym celem jest symulowanie kliknięcia w różne elementy na ekranie użytkownika.

Ale po co ktoś chciałby stosować takie oprogramowanie?

Odpowiedź jest prosta - dla pieniędzy.

Dalej bowiem na komputerze ofiary instalowane są różnego rodzaju downloadery oferowane przez programy partnerskie.

Schemat działania tego rodzaju firm jest prosty.

Załóżmy - że jesteś twórcą jakiegoś programu.

Masz sporo pieniędzy i chciałbyś go wypromować wśród nowych użytkowników.

Kontaktujesz się więc z siecią reklamową w celu zawiązania umowy.

Ta to sieć - gwarantuje Ci nowe instalacje Twojego programu, w zamian za to Ty - będziesz płacił za taką instalację odpowiednią sumę pieniędzy.

Potem to sieć reklamowa nawiązuje współpracę z innymi twórcami popularnych, darmowych programów.

Oni to w swoich instalatorach dodają odpowiedni kod.

Dzięki temu, podczas instalowania darmowego oprogramowania - oprócz niego użytkownik końcowy otrzymuje propozycję instalacji dodatkowych narzędzi.

Jeżeli się na nie zgodzi - twórca otrzymuje za każdą taką instalację dodatkowe pieniądze.

Tylko, że w tym schemacie - użytkownik musi wyrazić zgodę na taką instalację.

Zazwyczaj - polega ona na kliknięciu w przycisk zezwalam/instaluj czy też dalej.

I to właśnie po to przestępcy najpierw uruchamiają swojego clickera.

On to monitoruje wszystkie, nowotworzone okna - i klika w odpowiednie ekrany tak, aby oprogramowanie zostało zainstalowane na komputerze użytkownika bez jego zgody.

W taki to sposób przestępcy zarabiają na osobach, które ściągają i uruchamiają nie do końca legalne rzeczy z Internetu.

Błąd w Facebooku

 Błąd w Facebooku

Facebook niedawno załatał błąd, który pozwalał na sprawdzenie, czy naszą stronę internetowa odwiedziła konkretna osoba, która jest obecnie zalogowana do Facebooka.

Na pozór tego rodzaju podatności to nic złego.

Wszak sam Facebook wie, że my - będąc do niego zalogowani, odwiedziliśmy daną witrynę.

Używa potem tego rodzaju informacji do wyświetlania targetowanych reklam.

Tylko, że tym razem - to twórca witryny uzyskiwał tego rodzaju informacje.

Może ten przypadek nie jest spektakularny, ale przychodzi mi tutaj do głowy inny, podobny przypadek.

Tyczył się on serwisu LinkedIn - czyli narzędzia używanego głównie przez rekruterów i osoby szukające pracy.

Jest to więc taki Facebook dla pracowników.

Każdy użytkownik może opisać swoje życie zawodowe, umiejętności, projekty.

Równocześnie, firmy szukające pracowników mogą się do nas zgłosić z propozycją pracy.

Jedną z dodatkowych, płatnych funkcjonalności jest opcja, pozwalająca na sprawdzenie, kto odwiedził nasz profil.

Widzimy wtedy, które firmy i konkretne osoby wchodziły na nasz profil.

Wiemy, czy może ktoś jest zainteresowany naszą praca i poczynaniami.

Ogółem - tego rodzaju dane są w szczególnych przypadkach bardzo wartościowe.

Ktoś jednak postanowił nadużyć ten mechanizm.

W jaki sposób?

Na swojej stronie internetowej umieścił niewidoczny gołym okiem piksel, który to miał wyświetlać stronę LinkedIn.

Na pierwszy rzut oka wydaje się to bezsensowne.

Po co ktoś miałby wyświetlać stronę, która nie będzie dla nikogo widoczna.

Wszak piksel 1x1 to zdecydowanie za mało aby coś dojrzeć.

Ale nie o to chodziło w całym tym mechanizmie.

Umieszczając niewidoczną podstronę prowadzącą na nasz profil, sprawialiśmy, że każdy kto odwiedzał naszą stronę równocześnie odwiedzał nasz profil na LinkedInie.

A jeżeli był tam zalogowany - jego dane były zapisywane w bazie serwisu.

A ponieważ płatni użytkownicy mogli sprawdzić, kto przeglądał ich profil - nagle uzyskiwaliśmy dostęp do imion i nazwisk osób, które nie tylko odwiedzały nasz profil, ale także nasza stronę internetową.

A to wszystko bez ich interakcji czy też zgody - wystarczyło tylko, że byli zalogowani na LinkedInie, a to nie jest zbyt rzadka praktyka.

Jak więc widzicie, błędy tego rodzaju mogą mieć różne konsekwencje w zależności od serwisu, na którym występują.

LinkedIn to jeden z gorszych pod względem prywatności przypadków, tam bowiem większość osób tworzy konta pod swoimi oficjalnymi imionami i nazwiskami.

Ale podobna sprawa może się tyczyć innych serwisów, z dowolnego rodzaju kontami.

Literówka w kodzie PHP

 Literówka w kodzie PHP

A teraz o meandrach języka PHP.

W sieci pojawił się opis podatności, w której to dzięki literówce możliwe było zdalne wykonanie kodu na serwerze.

Ale jak do tego doszło?

W pewnym momencie programista sprawdzał dane podane przez użytkownika.

Gdy nie spełniały one pewnych warunków, zwracany był fałsz - tak aby funkcje, które bazowały na tym sprawdzeniu wiedziały, że cała operacja się nie powiodła.

Tylko, że programista chciał zwrócić fałsz.

W rzeczywistości jednak zwracał prawdę.

Ale jak to możliwe?

W PHP za fałsz służy słowo kluczowe false.

W tym kawałku kodu zostało ono błędnie zapisane jako flase.

Ale jak to możliwe, że taki ciąg został potraktowany jako prawda?

PHP dość luźno podchodzi do typów danych.

Generalnie morza założyć, że język jest w stanie przekonwertować każdy typ danych podany przez użytkownika na taki, aby pasował do bieżącego kontekstu.

W kontekście instrukcji warunkowej if - PHP oczekuje prawdy albo fałszu.

Tutaj jednak otrzymał stałą flase.

Wartość ta bowiem nie była zawarta pomiędzy pojedynczym albo podwójnym cudzysłowem.

Nie była również prawidłową liczbą.

A jak można wyczytać w dokumentacji - tylko pusty ciąg znaków albo 0 jest rzutowane na fałsz.

Wszystko inne jest prawdą.

Dlatego też if (flase) daje nam prawdę.

Należy jednak zwrócić uwagę iż w standardowej konfiguracji programista otrzyma zawiadomienie o próbie użycia niezdefiniowanej wcześniej stałej.

W dużym serwisie jednak taka uwaga może być łatwo przeoczona.

Prywatność a rozmiar okna przeglądarki

 Prywatność a rozmiar okna przeglądarki

Nie od dziś wiadomo, że spora część serwisów Internetowych zarabia na wyświetlaniu reklam.

Czasy gdy każdemu z nas wyświetlały się te same reklamy już dawno minęły.

Reklamodawcy zdali sobie sprawę, że wyświetlanie tych samych przedmiotów dla wszystkich jest stratą pieniędzy.

Dużo lepsze rezultaty przynosi inne podejście do tematu - czyli targetowanie reklam.

Tutaj na podstawie działalności danej osoby w Internecie proponuje jej się takie materiały, które mogą być powiązane z jej zainteresowaniami czy też marzeniami.

Ale, żeby wiedzieć co wyświetlać - trzeba na jakiejś podstawie rozpoznawać użytkownika.

Jednym ze sposobów jest używanie rozmiaru okna przeglądarki.

Każda strona bowiem może pobrać wielkość naszego okna.

Może nam się wydawać, że taka informacja nie jest istotna - ale to błąd.

Wiele osób ma różne wielkości monitorów - co przekłada się na różne wielkości stron.

A jeżeli dzięki temu można podzielić użytkowników na dziesięć mniejszych grup - reklamodawca jest 10 razy bliżej zidentyfikowania danego użytkownika.

Firefox postanowił ukrócić tą praktykę wprowadzając nowość do swojej przegladarki.

Teraz za każdym razem gdy użytkownik będzie modyfikował rozmiar okna, będzie ono automatycznie rozszerzane do wielokrotności prostokąta 200x100.

Będzie to rozwiązane poprzez automatyczne dodawanie szarego pola dookoła strony internetowej.

Dla użytkowników będzie to kosmetyczna zmiana.

Po prostu w pewnych miejscach będzie widoczne dodatkowe szare tło.

Reklamodawcy jednak będą widzieli szerokości zaokrąglone do rządu setek - a to znacząco zmniejsza dokładność targetowania.

Jak działa atak czasowy?

 Jak działa atak czasowy?

Ostatnia wiadomość na dzisiaj.

Atak czasowy to atak, w którym intruz usiłuje skompromitować system poprzez analizę czasu, wymaganego do wykonania danej operacji.

Dzięki pomiarom czasu, wymaganego do odpowiedzi na poszczególne zapytania, możliwy jest przeciek informacji z systemu.

Na początku może się to wydawać jako coś trudnego i nierealnego do przeprowadzenia w rzeczywistości.

Dlatego spróbujmy to rozpatrzyć na przykładzie.

Załóżmy, że posiadamy stronę, która pozwala na wyszukiwanie artykułów na podstawie ich tytułu.

Dodatkowo artykuł może być publiczny a także ukryty - wtedy nie jest widoczny dla wszystkich użytkowników a tylko dla jego twórcy.

W wyszukiwarce oprócz liter możliwe jest wykorzystywanie pytajnika - który oznacza dowolną jedną literę.

Na początku należy zdefiniować przedziały ufności.

Najpierw 100 razy wykonujemy zapytanie, w treści podając fragment tytułu ukrytego postu i notujemy jego czas.

Następnie potwarzami czynność - tym razem używając wyrazu, który nie istnieje w naszej bazie.

Dla uproszczenia zakładamy tu tylko, że baza zawiera tylko jeden rekord.

Po przepuszczeniu tych czasów przez odpowiedni algorytm powinniśmy otrzymać przedziały czasowe.

One to definiują z odpowiednim prawdopodobieństwem bazując na czasie odpowiedzi serwera - czy post o podanym tytule istnieje w bazie danych.

Jeżeli czasy są bardzo zbliżone, najprawdopodobniej dana strona nie jest podatna na tego rodzaju atak albo tez okoliczności i warunki zewnętrzne nie pozwalają na jego przeprowadzenie.

Każde bowiem odchylenie od normy - chociażby wydłużony ping raz na kilka żądań, może podważyć bieżące rezultaty.

Jeżeli jednak widoczna jest różnica w czasie odpowiedzi - można przystąpić do dalszej analizy, tym razem próbując odgadnąć tytuł nieznanej nam wiadomości.

Najlepiej rozpocząć od wyznaczenia długości takiego tytułu.

Jak się do tego zabrać? Używając pytajników.

Każdy pytajnik to jedna litera - powtarzamy więc procedurę obliczania czasu żądania za każdym razem dodając dodatkowy pytajnik.

Jeżeli mamy szczęście, w pewnym momencie zauważymy różnicę w czasie odpowiedzi.

W taki sposób odgadujemy długość tytułu.

Teraz pora na sprawdzanie każdej litery po kolei.

Zamieniamy więc pierwszy pytajnik na literę a, potem b, c i tak dalej.

I znowu w pewny momencie powinniśmy zauważyć różnicę w odpowiedzi.

Przez to wiemy, że najprawdopodobniej na tym polu obecna jest właśnie ta litera.

Kontynuujemy więc nasze poszukiwania zmieniając kolejny pytajnik w kolejności ponownie na litery a, b i c.

Oczywiście, opisuję tu bardzo uproszczony przypadek, gdy w bazie istnieje tylko jeden rekord.

Więcej informacji na ten temat można znaleźć we wpisie autora publikacji.

Ja chciałem tu tylko przedstawić podstawy tego rodzaju ataku.

Icon made by Vectors Market, Freepik, Roundicons, monkik www.flaticon.com

1 2 3 4 5 6 7 8 9 10 11