Wprowadzenie
Cześć!
Ja jestem Kacper Szurek a to podcast Szurkogadanie, odcinek 37.
W tym tygodniu:
Podszywanie się pod okno przeglądarki na iPhone’ie - o ataku Picture in Picture.
Jak sprawdzić gdzie byliśmy na wakacjach bez naszej zgody? O podatności Cross-site Search.
Czy słyszałeś o Google BigQuery? Przeszukiwanie wielu gigabajtów danych w celu odnalezienia tokenów API na GitHubie.
Jak podszyć się pod dowolny adres IP? O zdalnym wykonaniu kodu w infrastrukturze Mozilli.
Używanie legalnych komponentów do rozpowszechniania złośliwego oprogramowania - jak wykorzystano serwis Firebase.
Oszustwa w mechanizmie reklam mobilnych - jak wyświetlać dwie reklamy w jednej.
Co to jest high frequency trading i jakie przeszkody stoją przed osobami, które się nim zajmują.
A także o last minute persistence, czyli jak ewoluowały metody przetrzymywania restartu komputera w malwarze.
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 Podcasty.
Więcej informacji na temat bezpieczeństwa znajdziesz na naszej grupie od 0 do pentestera na Facebooku.
Zapraszam do słuchania.
Technika Picture in Picture
Ponowne użycie techniki Picture in Picture - tym razem ofiarą padli użytkownicy iPhone’ów.
Co to za metoda i jak wygląda?
Jest to względnie nowa technika wykorzystywana w atakach phishingowych.
Tworzy się tam obrazek, łudząco przypominający okno przeglądarki internetowej.
Jest tam zatem prawidłowa nazwa domeny, zielona kłódeczka i wszystkie informacje wyświetlane przez normalne okno chociażby Chrome’a.
Tylko, że nie jest to okno przeglądarki, a zwykła grafika wyświetlana w obrębie danej strony internetowej.
Ma ona tylko symulować to okno tak, aby przekonać niczego nieświadomych użytkowników do podania swoich danych do logowania.
Użytkownik widzi bowiem prawidłową nazwę domeny i zieloną kłódeczkę - więc wydaje mu się że wszystko jest ok.
Kilka miesięcy temu ta technika wykorzystywana była w atakach na użytkowników Steama.
Tym razem - łupem padały konta Facebooka, kiedy to użytkownicy korzystali z iPhone’ów.
W Safari bowiem - czyli natywnej przeglądarce używanej w tym systemie operacyjnym, jeżeli przeskrolujemy daną stronę w dół - pasek z miejscem na nazwę domeny znika - tak aby jak największa część strony była widoczna.
Pozostaje jedynie mała informacja z nazwą domeny i kłódeczką u samej góry.
Wykorzystują to przestępcy.
Jak działa atak?
Tworzą witrynę, którą aby zobaczyć - należy najpierw zalogować się do Facebooka.
Po kliknięciu w link - otrzymujemy informację, która pyta nas czy chcemy tą stronę otworzyć w aplikacji Facebooka.
To pierwszy trick stosowany w całym procederze.
Okienko to jest łudząco podobne do tego używanego przez system - tylko, że jest to zwykła grafika.
Okno to bowiem nie otwiera aplikacji Facebooka.
Dalej - otwierana jest nowa zakładka.
U góry widzimy pasek adresu - facebook.com i kłódeczkę, a na dole miejsce na nasz login i hasło.
Tylko wprawne oko zauważy - że prawdziwa nazwa domeny, pod którą się obecnie znajdujemy jest wyświetlana u samej góry - małą czcionką.
Cała reszta to dobrze przygotowany obrazek.
Tego rodzaju ataki są bardzo niebezpieczne i łatwo się na nie nabrać.
Zwłaszcza, że używając komórek nie przykładamy takiej uwagi do wszystkich szczegółów.
Wszak ekrany są małe i nie zawsze wszystko wyświetla się prawidłowo.
Co więcej, wyglądy przeglądarek co jakiś czas się zmieniają.
Statystyczny użytkownik może bowiem nie być świadomy jak dana funkcja obecnie wygląda.
Jak zatem ochronić się przed tego rodzaju atakami?
Po pierwsze możemy korzystać z menadżerów haseł.
W tym wypadku - takie menadżery nie podpowiedzą nam naszego hasła do Facebooka - ponieważ znajdujemy się na innej domenie, do której hasła nie mamy zapisanego.
Jest to zatem pierwsza czerwona flaga.
Druga metoda - to używanie 2FA.
Ale o tym już nie raz wspominałem w tym podcaście.
Cross-site Search
Czasy, gdy posiadając aparat robiliśmy tylko kilkanaście zdjęć już dawno minęły.
Jednym z punktów sprzedażowych topowych smartfonów są coraz to lepsze aparaty w nie wbudowane.
To sprawia - że z roku na rok ilość wykonywanych zdjęć a także ich wielkość - stale rośnie.
Przez to coraz większa ilość osób przenosi swoje cyfrowe archiwa do chmury.
Tak jest po prostu taniej, szybciej i bezpieczniej, a dodatkowo mamy dostęp do tych zasobów z każdego miejsca na ziemi.
Jednym z popularnych serwisów pozwalających na przechowywanie zdjęć jest Google Photo.
Ale samo przechowywanie zdjęć to nie wszystko.
Wykorzystując sztuczną inteligencję witryna analizuje każdy z przesłanych materiałów, odpowiednio tagując informacje, które tam znalazła.
Dzięki temu możemy przeszukiwać nasze zdjęcia używając języka naturalnego, wpisując chociażby frazę w stylu: zdjęcia moje i Piotrka z wizyty w Paryżu w 2018.
AI bowiem nie tylko rozpoznaje przedmioty i krajobrazy, ale także sylwetki osób, znajdujących się na zdjęciach.
No dobrze, ale co w tym złego?
Obecnie, popularność zyskują ataki Cross-site Search.
I niech nie zwiedzie Cię początek nazwy, który może Ci się kojarzyć z atakami XSS - czyli wykonaniem nieautoryzowanego kodu JavaScript na naszej stronie internetowej.
Tutaj bowiem rezultaty zależą od czasu wykonania.
Jak zatem przebiega cały atak i jak może być wykorzystany?
Wchodząc na złośliwą stronę, inicjalizuje ona kilkadziesiąt żądań do serwerów Google.
Zapytania te symulują wyszukiwania, które byłyby wykonywane przez zwykłego użytkownika.
Zazwyczaj jeżeli korzystamy na co dzień z usług internetowego giganta, to jesteśmy zalogowani na swoje konto Google.
To sprawia - że takie żądanie do Google Photo powiedzie się - ponieważ przeglądarka automatycznie wyśle ciasteczko, na podstawie którego serwer rozpozna że my to my.
Ale w standardowej ścieżce pentestera - tutaj cała sprawa się kończy.
Ponieważ serwer jest bezpieczny i zewnętrzna strona nie ma jak pobrać danych, które zostały zwrócone przez serwer.
A to wszystko dzięki mechanizmowi Same Origin Policy.
I tu do gry wchodzi Cross-site Search.
Zła witryna nie może pobrać zwróconych przez serwer danych.
Ale - może sprawdzić, jak długo żądanie miało miejsce.
Na początku zatem wykonuje się zapytanie, które na 99% nie zwróci żadnych wyników.
Tak wylicza się średni czas odpowiedzi.
Następnie - wykonuje się inne zapytanie, z interesującym nas pytaniem.
Na przykład Włochy 2018.
Jeżeli serwer posiada zdjęcia z tego okresu - istnieje spore prawdopodobieństwo, że odpowiedź będzie trwała nieco dłużej, niż wcześniej wyliczony przez nas średni czas odpowiedzi.
Powtarzając cały mechanizm kilkadziesiąt lub nawet kilkaset razy możemy zminimalizować resztę czynników, które mogłyby mieć wpływ na przeprowadzany atak - takie jak chociażby straty pakietów po drodze.
Dzięki temu - możemy uzyskiwać odpowiedź na proste pytania w stylu tak/nie bazując jedynie na czasie odpowiedzi.
Ten sam błąd został w przeszłości wykorzystany w Bug Trackerze Chrome’a.
Tam to - można było zadawać podobne pytania, sprawdzając chociażby czy istnieje jakiś niezałatany jeszcze błąd w konkretnym pliku z kodu źródłowego.
Na pierwszy rzut oka może się zdawać, że błędy tego rodzaju nie są takie krytyczne.
Wszak mamy do czynienia z dużą ilością zmiennych, które wpływają na wynik.
Nie jest to bowiem prosta i szybka odpowiedź, taka jak chociażby w przypadku ataków SQL Injection - kiedy to po prostu strona zwraca jakiś rekord z bazy danych.
Ale wszystko zależy do czego chcemy wykorzystać zebrane w ten sposób dane.
W przypadku standardowego użytkownika sieci - można założyć, że wyciek informacji jest minimalny.
Wszak zapewne te lub podobne dane znajdziemy po prostu przeglądając różne serwisy społecznościowe czy też tweety, z hasztagami miejsc, w których dana osoba się znajdowała.
Ale co w przypadku osób, które bardzo cenią swoją prywatność?
Jeżeli bowiem ktoś korzysta z przeglądarki TOR a dodatkowo jest zalogowany na jakimś serwisie, który jest podatny na Cross-site Search - to metoda ta może doprowadzić do ujawnienia jego tożsamości.
Zwłaszcza, ze Internet jest coraz szybszy a opóźnienia i straty pakietów coraz mniejsze.
Jak działa Google BigQuery?
Czy słyszałeś o Google BigQuery?
Jest to działająca w chmurze hurtownia danych zoptymalizowana pod kątem szybkiej analizy dużych zbiorów danych.
Czyli tłumacząc to na proste słowa: wielka baza danych, która pozwala na wyszukiwanie informacji z zasobów liczących setki gigabajtów.
Zazwyczaj technologia ta używana jest w kontekście Business Intelligence, kiedy to duże firmy chcą analizować dane na temat swoich użytkowników.
Ale ja chciałbym opowiedzieć o innych użyciu tego narzędzia.
Google przechowuje bowiem w tej usłudze tak zwane Public Datasets.
W bazie znajdują się zatem informacje z pytaniami programistów z forum StackOverflow, dane na temat pożarów w San Francisco czy też 3.5 miliona książek, które zostały skonwertowane na postać cyfrową.
Są tam również dane z serwisu GitHub - czyli jednego z większych serwisów przechowujących publiczne i prywatne repozytoria gita - czyli systemu kontroli wersji używanego przez programistów na całym świecie.
I to właśnie te ostatnie dane zostały wykorzystane przez naukowców w najnowszych badaniach.
Ich cel był prosty - sprawdzić jak często zdarza się, że programiści w swoich kodach umieszczają klucze API - które z założenia powinny być tajne.
Poprzednie badania opierały się głównie na wyszukiwarce wbudowanej w serwis.
Ta jednak posiada pewne ograniczenia.
Przede wszystkim nie są możliwe zaawansowane zapytania - czyli takie, które używają wyrażeń regularnych.
Dodatkowo, wyszukiwarka indeksuje jedynie pliki mniejsze niż 384 KB.
Maksymalnie zwraca również 1000 rezultatów.
To sprawia, że dane pozyskiwane w taki sposób nie są pełne.
Dodatkowa analiza przy użyciu Google Big Query - może wypełnić tą lukę.
Jednak nie całkowicie - tam znajdują się bowiem jedynie informacje z repozytoriów, które posiadają ustawioną licencję, która na to zezwala.
To sprawia - że naukowcy nie posiadają dostępu do całej bazy GitHuba a tylko jej części.
Badanie wyglądało następująco:
Najpierw przy pomocy wyszukiwarki oraz BigQuery poszukiwano plików, w których potencjalnie mogły się znajdować klucze API.
W tym celu używano kilkunastu różnych zapytań.
Poszukiwano między innymi słów access_token, access_secret, secret_key, private_key.
W przypadku bazy danych, używano bardziej zaawansowanych wyrażeń regularnych.
W ten sposób poszukiwano tokenów Amazona, Google oraz Twittera.
Po uzyskaniu nazw plików, ściągano ich treści które to były następnie odpowiednio filtrowane.
Całe badanie trwało pół roku.
Jakie są wnioski?
19 procent opublikowanych kluczy zostało usunięte z repozytoriów w przeciągu 16 dni.
To pokazuje, że ze sporej części wycieków programiści zdają sobie sprawę i nie są one celowe i wynikają z ludzkiego błędu.
Oprócz tokenów API odnaleziono ponad 7000 kluczy RSA, które znajdowały się w plikach konfiguracyjnych OpenVPN.
Przy ich użyciu możliwe było połączenie z danym serwerem bez posiadania hasła.
W tym miejscu należy zwrócić uwagę iż GitHub już od pewnego czasu traktuje sprawy wycieków takich informacji w bardzo poważny sposób.
W tym serwisie działa tak zwany token scanning - czyli system, sprawdzający całe repozytoria w poszukiwaniu kluczy należących do kilku największych firm.
W przypadku odnalezienia tokenu w publicznym kodzie - dane na temat takiego klucza są automatycznie wysyłane do firmy, która go wystawiła, a następnie blokowane.
Dzięki temu użytkownicy tego serwisu posiadają dodatkową linię obrony w przypadku swoich błędów.
Co jednak z innymi serwisami tego rodzaju?
To również pokazuje siłę Big Query.
W przeszłości już kilkukrotnie używano tego mechanizmu do badań na temat bezpieczeństwa.
Jednym z ciekawszych badań jest poszukiwanie w repozytoriach kluczy prywatnych różnych kryptowalut.
Jak widać, wyszukiwarka może być zatem używana na wiele interesujących sposobów.
Niestety, nie jest ona darmowa.
Płaci się za przechowywane dane a także za ilość przeprocesowanych informacji.
Jeżeli jednak masz ciekawy pomysł, pierwszy terabajt wykorzystany przez zapytanie jest darmowy.
Błąd w konfiguracji narzędzia WebPageTest
A teraz o błędzie, który pozwolił na uzyskanie dostępu do infrastruktury AWS firmy Mozilla.
Firma używała narzędzia WebPageTest, które to pozwala na sprawdzenie szybkości ładowania się stron z różnych lokalizacji.
Kod składa się z interfejsu webowego a także agenta, który to uruchamia testy z poziomu przeglądarki.
Prywatne instancje tego narzędzia zazwyczaj są zabezpieczone loginem i hasłem - tak, aby osoby z poza organizacji nie mogły z niego korzystać.
Tym razem jednak ta instancja była dostępna dla wszystkich.
Ale to nie jedyny błąd.
Jeżeli żądanie do GUI pochodziło z lokalnego serwera - czyli z adresu IP 127.0.0.1 możliwe było wysłanie pliku ZIP, którego to treść była zapisywana na serwerze.
Takie funkcje są idealnym miejscem dla pentestera.
Całość bowiem napisana jest w języku PHP.
To oznacza, że serwer serwujący te pliki musiał posiadać ich obsługę.
Jeżeli zatem możliwe było zapisanie pliku z rozszerzeniem .php - mogło to doprowadzić do zdalnego wykonania kodu.
Wystarczyło bowiem spreparować złośliwe archiwum wraz z naszym kawałkiem kodu PHP i wysłać go na serwer.
Jeżeli plik zostałby wypakowany do lokalizacji dostępnej z poziomu przeglądarki - dochodzi do jego wywołania i uruchomienia zapisanego przez nas wcześniej kodu.
Programiści zdawali sobie jednak sprawę z tego potencjalnego zagrożenia i dodali do kodu dodatkowy mechanizm zabezpieczający.
Archiwum najpierw było wypakowywane, a następnie specjalna funkcja sprawdzała rozszerzenia wszystkich plików.
Te z końcówką .php, .cgi czy też .py były automatycznie usuwane z serwera, tak aby nie można ich było wykorzystać do ataku na daną instancję.
Mamy tutaj zatem do czynienia z dwoma mechanizmami zabezpieczającymi.
Po pierwsze wysyłka plików możliwa jedynie z jednego, specyficznego adresu IP.
Po drugie - teoretyczny brak możliwości wysyłki plików .php.
Ale nie wystarczy zabezpieczać swój kod, należy to robić w prawidłowy sposób.
Jak zatem udało się ominąć te dwa mechanizmy?
Sporo dzisiejszych stron korzysta z usług CDN-ów, czyli firm, które pośredniczą w ruchu pomiędzy klientem i serwerem.
Chociażby Cloudflare.
Zwykły użytkownik bowiem przeglądając witrynę nie łączy się z nią bezpośrednio.
Najpierw wysyła żądanie do Cloudflare - a następnie ta to firma łączy się z serwerem danej strony.
To sprawia - że serwer nie widzi adresu IP klienta, a IP serwera maszyny należącej do CDN-a.
Aby ominąć ten problem, wiele CDNów ustawia odpowiedni nagłówek w żądaniu, w którym to podaje prawidłowy adres IP klienta, który łączy się przy ich pomocy z daną witryną.
W tym kodzie obsłużono taki przypadek - używając nagłówka HTTP_FASTLY_CLIENT_IP, kiedy to żądanie pochodziło z serwerów Fastly.
Atakujący mógł więc podmienić swój prawdziwy adres IP, wysyłając do serwera żądanie z tym konkretnym nagłówkiem.
W taki sposób ominięto pierwszą blokadę, ale co z usuwaniem plików .php?
Jeżeli słuchałeś tego co mówiłem wcześniej dokładnie - wiesz już, że serwer najpierw wypakowuje pliki do odpowiedniej lokalizacji a dopiero potem je usuwa.
A to bardzo zły pomysł - ponieważ może dojść do race condition.
Wykorzystanie tego błędu wygląda zatem następująco:
Wysyłamy kilkaset żądań do serwera na sekundę - wraz ze złośliwym archiwum.
Serwer musi obsłużyć każde żądanie, to znaczy wypakować treść pliku do odpowiedniego katalogu a następnie każdy z tych plików odpowiednio przeprocesować i usunąć jeżeli jest niewłaściwy.
Tylko, że my w tym samym czasie wysyłamy kolejne kilkaset żądań - próbując odwiedzić nasz złośliwy plik.
Po pewnym czasie - dojdzie do sytuacji, w której serwer nie zdąży usunąć pliku PHP przed nami.
Dzięki temu - nasz złośliwy kod zostanie wykonany.
Dwa subtelne błędy połączone w jeden, działający ciąg.
Używanie Firebase do dystrybucji malware
W świecie złośliwego oprogramowania trwa nieustanna walka pomiędzy twórcami i osobami, chroniącymi użytkowników przed przestępcami.
Tym razem o malwarze dystrybuowanym na stronach internetowych.
Pomysł jest prosty - wyświetla się reklamy, które informują ofiarę iż musi ona zaktualizować swoją wersje Adobe Flash Playera.
Nie wykorzystuje się tutaj żadnych błędów czy też exploitów, a czystą socjotechnikę.
Użytkownik musi bowiem samemu pobrać i uruchomić złośliwy plik.
Kod wyświetlający takie reklamy bardzo ewoluował.
Jest on zobfuskowany - czyli napisany w taki sposób, aby jego analiza była znacząco utrudniona.
Z jednej strony jest to zła wiadomość dla osób analizujących dane oprogramowanie.
Z drugiej jednak strony taki kod nie wygląda jak nic, co mogło by być pisane ręką człowieka.
Dużo losowych zmiennych, dziwne nazwy i konstrukcje niespotykane w realnym kodzie.
To sprawia, że nawet osoby słabo zaznajomione z informatyką intuicyjnie mogą domyślać się, że coś w tym przypadku jest nie tak.
Ale zasady gry co chwilę się zmieniają.
Teraz widoczny jest trend, gdzie przestępcy starają się jak najbardziej upodobnić swój złośliwy kod do tego, pisanego przez zwykłych programistów.
Jaka sztuczka została użyta tym razem?
Firebase to platforma używana głównie przez twórców aplikacji mobilnych.
Udostępnia ona między innymi bazy danych noSQL.
Można się z nimi łączyć bezpośrednio z aplikacji mobilnej i zapisywać czy też pobierać interesujące dane w czasie rzeczywistym.
Tym razem jednak mechanizm ten został użyty przez twórców złośliwego oprogramowania.
Wykorzystali oni kawałek kodu, który to łączy się z taką bazą danych a następnie pobiera z niej jeden rekord.
Treść tego rekordu jest następnie przekazywana do funkcji eval - co sprawia, iż kod tam się znajdujący jest wykonywany przez przeglądarkę.
Na pierwszy rzut oka nie ma tu zatem niczego złego.
Ot jakiś programista testuje nową technologię, wykorzystując przykład z manuala pobiera jakiś rekord i wyświetla go na stronie.
Cała złośliwa treść jest bowiem przechowywana w bazie danych Firebase.
A sprawdzając tą domenę - widzimy, że jest ona zaufana i wykorzystywana przez wiele osób na całym świecie.
To nie jedyny przykład gdzie złośliwe oprogramowanie wykorzystuje popularne strony.
Mieliśmy już do czynienia z przypadkami przechowywania złośliwych informacji na GitHubie, Twitterze czy też Facebooku.
Każde dane można bowiem odpowiednio zaszyfrować tak, aby bez odpowiedniego klucza nie były zrozumiałe dla nikogo.
Reklamy a bateria
Gry i programy mobilne to coraz większy rynek.
Wszak większość z nas przynajmniej kilkadziesiąt minut dziennie spędza w autobusie, pociągu czy też samolocie.
Wtedy to można słuchać muzyki, czytać książkę lub też zagrać w prostą grę na telefonie.
Tutaj - nieco inaczej niż na komputerach i konsolach, królują mikropłatności, a także reklamy.
Ciężej jest bowiem zmusić użytkownika do kupna gry od razu - w ciemno.
Łatwiej natomiast przekonać go do wyświetlenia jakiejś reklamy przez kilka sekund w zamian za kolejne życie czy też dodatkowe funkcje w grze.
Dla wielu osób tworzenie takich gier i aplikacji to sposób na zarabianie pieniędzy.
Ale jak to bywa - reputację buduje się szybko, a stracić ją można w kilka sekund.
Jak to bowiem możliwe, że nasza aplikacja, którą z taką dumą budujemy od dłuższego czasu i dbamy o każdego potencjalnego klienta naprawiając wszystkie błędy, nagle zaczyna otrzymywać negatywne oceny w markecie?
Nagle widzimy informacje o szybkim zużywaniu się baterii a także o wielu megabajtach danych pobieranych przez telefon.
Jak to możliwe?
Okazuje się, że przez reklamy.
Tam to kwitną nielegalne praktyki na których to zarabia wielu pośredników, a tracą jedynie twórcy aplikacji.
Jak działa cały schemat?
Każdy właściciel gry może określić kiedy pojawią się reklamy oraz jaka jest ich wielkość oraz czas trwania.
Następnie takie miejsce może zostać wykupione przez jakąś firmę do promowania swoich własnych treści.
Jak można się domyślać ceny zależą od popularności aplikacji ale również wielkości danej reklamy.
Oczywistym wydaje się być fakt iż reklama pełnoekranowa, która blokuje rozgrywkę jest droższa niż baner na samym dole telefonu.
Niektórzy postanowili nadużyć ten mechanizm.
Wykupują takie tanie reklamy i przynajmniej w teorii reklamują różne produkty i usługi przy ich pomocy.
Tylko, że w tle - oprócz tej malutkiej reklamy, wyświetlają długą reklamę wideo.
Jest ona niewidoczna dla użytkownika z powodu specjalnego kodu z jakiego korzysta.
Dalej jednak materiały do tej reklamy są pobierane z Internetu a reklamodawcy płacą za tak wyświetloną reklamę.
Wszak oni to nie posiadają informacji, że reklama jest wyświetlana w taki sposób, że użytkownik jej nie widzi.
A zarabia na tym dodatkowy pośrednik - który wykorzystując małe miejsca reklamowe, wyświetla dużo droższe reklamy.
A cała różnica to zysk, który zostaje w jego kieszeni.
I rzeczywiście - jeżeli mała reklama widoczna jest cały czas a w tle pobiera ona inne, większe i wyświetla je w kółko - telefon cały czas zużywa zasoby oraz moc obliczeniową.
A cały hejt spływa na twórcę danej aplikacji - wszak tylko ona w danym momencie jest uruchomiona.
Tylko, że twórca nie ma większego wpływu na cały proceder.
Wszak - on tylko wypożycza miejsce, które to jest sprzedawane przez duże agencje, które to powinny weryfikować wszystkie wyświetlane reklamy.
Tylko, że to nie do końca leży w ich interesie.
Wszak - te większe reklamy, mogą również należeć do ich klientów - a od każdego takiego wyświetlenia otrzymują prowizję.
Interesujący rynek - w szczególności dla firm, reklamujących swoje produkty, jak bowiem sprawdzać, czy wszystkie wyświetlenia są prawdziwe?
Automaty w bankach
Żyjemy w czasach, w których praktycznie każdy element naszego życia jest zautomatyzowany.
Ta automatyzacja istnieje również w bankach.
Coraz częściej to automaty ocenią naszą zdolność kredytową, proponują kartę z odpowiednim limitem bazując na operacjach wykonywanych na koncie, czy też korzystne lokaty w momencie, gdy chcemy przenieść nasze fundusze do innego banku.
To są rzeczy, które widzimy na co dzień.
Ale istnieje też inny, większy niewidoczny dla postronnych osób, świat handlu wysokich częstotliwości.
Jest to technika inwestowania polegająca na zawieraniu wielu transakcji giełdowych w jak najkrótszym czasie
Tutaj decyzje podejmują algorytmy.
Zysk z jednej transakcji zazwyczaj nie przekracza ułamkowych części grosza.
Jeżeli jednak pomnożymy te części przez wielką ilość transakcji - możliwy jest spory zysk.
Tutaj liczą się każde milisekundy.
Największe firmy z tej branży stawiają swoje komputery jak najbliżej budynków giełdy.
Im bliżej bowiem giełdy są, tym szybciej mogą przesyłać do niej swoje transakcje.
Ale ten mechanizm, podobnie jak i cała giełda, zachowuje się dziwnie w przypadku kryzysu.
Widać to na wielu przykładach - kiedy to do mediów przedostają się złe informacje na temat jakiejś firmy - jej wycena momentalnie spada.
To samo widoczne jest tutaj - tylko, że tym razem nie decydują o tym ludzie, a algorytmy.
One to nieustannie przeszukują Internet, sieci społecznościowe i Twittera w poszukiwaniu najciekawszych informacji, które mogłyby wpłynąć na wycenę danych firm.
I tu pojawia się problem.
Co bowiem, jeżeli złośliwy aktor posiada wiedzę na temat modelu, który jest używany przez daną firmę?
Wie wtedy jakie informację algorytm bierze pod uwagę, jak je ocenia i analizuje.
Wie zatem co należy zrobić, aby robot podjął niekoniecznie dobrą decyzję.
W przyszłości możemy mieć zatem do czynienia z fałszywymi kampaniami informacyjnymi.
Takie rzeczy miały już miejsce.
Weźmy chociażby przypadek z 2013 roku, kiedy to przejęto konto Associated Press na Twitterze.
Użyto go do wysłania szokującej wiadomości: eksplozja w białym domu, prezydent ranny.
To wystarczyło, aby na giełdzie pojawił się znaczący spadek.
Ludzkość za jakiś czas może zatem stanąć przed nie lada problemem.
Jak rozpoznać prawdziwą wiadomość od tej zmyślonej?
Najprostszy algorytm to sprawdzenie jak wiele serwisów opisze ten sam incydent.
Tylko, że ta metoda nie na wiele się zda.
Wszak obecnie, wiele serwisów kopiuje swoje treści - delikatnie tylko zmieniając użyte w artykule słowa.
Czy to zatem koniec dziennikarstwa jakie znamy obecnie?
Last minute persistence
Kiedy mówimy o złośliwym oprogramowaniu to jedną z pierwszych rzeczy jaką zazwyczaj wykonuje malware na komputerze ofiary jest uzyskanie persystencji w systemie.
Tłumacząc to na prostsze słowa: wykonanie czynności, które pozwalają na przetrwanie ponownego uruchomienia systemu operacyjnego.
Czyli - złośliwy kawałek kodu powinien się ponownie uruchomić, tym razem już bez udziału użytkownika, kiedy ten ponownie uruchomi swój komputer.
Jednym z bardzo popularnych miejsc, które służą właśnie do tego celu jest folder Autostart.
W Windowsie - wszystko co znajduje się w tym folderze zostanie automatycznie uruchomione wraz z uruchomieniem systemu operacyjnego.
Zatem malware po zainfekowaniu - dodaje tam swój wpis.
Tak to się dzieje zazwyczaj.
Ale jak to mówią - od każdej reguły istnieją wyjątki.
Teraz, możemy się natknąć na sformułowanie: last minute persistence.
W tym to podejściu zapis złośliwego pliku do katalogu autostart wykonywany jest jak najpóźniej się da.
Skąd taka nagła zmiana?
Nie jest niczym odkrywczym iż często sprawdzając komputer pod kątem trojanów sprawdza się właśnie ten katalog jako jedno z pierwszych miejsc, które może być używane w zły sposób.
Dzięki temu możliwe jest szybkie natrafienie na plik - który może być głęboko schowany w odmętach dysku twardego.
Jeżeli takiego wpisu nie ma - znalezienie złośliwego kawałka kodu - jest znacząco utrudnione.
Przestępcy działają zatem następująco.
W tle, nasłuchują - czy nie następuje czasem zamknięcie systemu.
Jeżeli system wysyła taki sygnał - uzyskują swoją persystencję.
Ale to nie wszystko. W momencie swojego ponownego uruchomienia po restarcie - usuwają wcześniej stworzony rekord.
Nie jest on już potrzebny - aż do momentu gdy ponownie system będzie zamykany.
Wtedy to zostanie po raz kolejny stworzony - na ten krótki moment, kiedy to komputer nie jest używany.
Oczywiście takie podejście ma jedną wadę - w przypadku Blue Screena - czyli ekranu śmierci, kiedy do system z nieznanych sobie powodów się zawiesza - uzyskanie persystencji nie będzie możliwe.
Z drugiej jednak strony - takie podejście znacząco utrudnia odnalezienie złego pliku.
Przykład jak podejście przestępców zmienia się wraz z czasem.
I to już wszystko w tym tygodniu.
Zapraszam do komentowania i lajkowania i widzimy się już za tydzień.
Cześć!
Icon made by Freepik, Smashicons, itim2101 www.flaticon.com
