Wampiryczny blog

Korzystam z wielu usług oferowanych przez Google. Korzystam, ale im nie ufam. Nie, nie chodzi o to, że ktoś czyta moje maile albo przegląda wydarzenia w kalendarzu. Chodzi o to, że usługa, z której korzystam może sobie zniknąć. Ot tak.

Tym razem chodzi o Inbox. Korzystam z tej usługi od kiedy tylko było to możliwe i pasuje mi dużo bardziej niż Gmail. Mówię to przede wszystkim o aplikacji mobilnej. I co? I to:

Inbox by Gmail is going away at the end of March 2019. Use the new Gmail to help you get more done and continue your conversations without interruption.

Dawno, dawno temu pisałem, że byłbym w stanie zapłacić za usługę polegającą na doborze i prezentowaniu interesujących mnie treści. Dobór miałby polegać na merytorycznej weryfikacji zawartości, prezentacja - cokolwiek (to były jeszcze zamierzchłe czasy gdy RSS był nowy i trendy). Cóż, dalej czekam na taką usługę.

Usług oferujących feed newsów jest sporo, wystarczy wymienić Google News (Wiadomości Google), czy Wiadomości (Microsoft), do tego taki feed jest oferowany w przeglądarkach (choćby Chrome, Edge). W dalszym ciągu to nie to.

Po pierwsze jakość informacji - przeraźliwie niska. Nie, nie jest dobrze, gdy 50% kanału "Nauka i technika" stanowią artykuły o grach komputerowych. Do tego informacje o nowych telefonach/tabletach/zegarkach oraz "spadochroniarze" typu "Kandydat na prezydenta ugodzony nożem" (przykład błędnej klasyfikacji treści). Podobnie w innych kategoriach. W zasadzie nie - w porównianiu z innymi kategoriami "Nauka i technika" nie wypada tak źle.

Po drugie duplikacja treści - OK, rozumiem, ten sam temat może być poruszany w wielu źródłach, wolałbym jednak, by w takich przypadkach następowało grupowanie treści. Niby próby są podejmowane, ale wciąż daleko temu do używalności (nie mówiąc o doskonałości).

Po trzecie niedopasowanie treści do odbiorcy - zarówno Microsoft jak i Google mają mnie dość dobrze sprofilowanego (w to nie wątpię). Czy nie można tej wiedzy wykorzystać do tego, by przestać prezentować mi treści, które mnie nie zainteresują? Co więcej, mimo możliwości oznaczania w aplikacji artykułów, które mnie (nie)interesują nie widzę wielkiego wpływu takich działań na prezentowanie później treści.

Po czwarte głupie pomysły EU wygoda użytkowania - nie, nie podoba mi się to, że po otwarciu strony z artykułem muszę się przeklikać przez kilka okienek informacyjnych o cookies, danych osobowych i tak dalej. Tak wiem, obowiązki informacyjne i tak dalej...

(....) i jest tego więcej...

Czekam na zakończenie The new month of Burp pr0n i możliwość przetestowania (w praktyce) opisywanych zmian. W tym samym czasie chciałbym porównać jego możliwości z OWASP ZAP.

Co do zasady nie mam złudzeń, Burp jest bardziej kompletnym, dopracowanym narzędziem, ale jest kilka obszarów, w których ZAP ma ciekawe pomysły. Choćby spider/crawler, który w Burp również ma zostać znacząco ulepszony (patrz: Burp's new crawler).

Jedna rzecz się nie zmieni, Burp nie stanie się narzędziem fire and forget. To, że nie jest on w stanie zaadresować błędów logiki biznesowej jest oczywistością, wyzwaniem mogą być również skanowanie prostych technicznych usterek jeśli skaner nie jest w stanie odtworzyć prawidłowej ścieżki wywołania danej funkcji. Tu też należy spodziewać się ulepszeń (patrz: Automatically maintaining session during scans), ale nie wierzę, że rozwiązanie będzie kompletne. Niemniej jednak z chęcią sprawdzę jak Burp będzie sobie radził choćby z ochroną przez CSRF, obecne rozwiązania, Using Burp's Session Handling Rules with anti-CSRF Tokens, do najwygodniejszych nie należy.

Jest jeszcze jedna rzecz, której brakuje mi i w Burp, i w ZAP - dokładnego logowania wszystkiego co jest wysyłane do serwera w celu późniejszej analizy. Tak, są rozszerzenia (Logger++), można zapisywać logi do pliku tekstowego, ale nie są to rozwiązania wygodne. Ciągle chyba najlepszym rozwiązaniem jakie widzę, to puszczenie całego ruchu przez kolejne proxy (np. Fiddler) i zachowanie również tych logów na wypadek, gdyby w przyszłości zaszła potrzeba przeanalizowania co (nie)zostało zrobione.

Po drugim dniu konferencji mam pewien niedosyt. Agenda była ułożona w taki sposób, że prezentacje, które mnie interesowały najbardziej odbywały się często równolegle.

XSS is dead. We just don't get it. - tak, oddawna mamy (prawie) wszystko, co potrzebne by wygrać z XSS. Trzeba tylko z tego korzystać. Mimo wszystko jednak nie wierzę, że pozbędziemy się XSS w przewidywalnej przyszłości. To nie jest tak, że w developerach upatruję całego zła tego świata, ale z drugiej strony mam bolesną świadomość jak niektóre zespoły developerów są tworzone/kompletowane, jak często się zmieniają i jak wygląda poziom świadomości odnośnie secure coding.

A na tej prezentacji niestety nie byłem. Defense-in-depth techniques for modern web applications and Google's journey with CSP. Temat CSP jak najbardziej powiązany z prezentacją Mario. Tak, CSP jest fajnym narzędziem, ale jest skomplikowane. Bardzo. Jeśli ktoś potrafi z niego prawidłowo korzystać, prawdopodobnie jest w stanie użyć również pozostałych narzędzi do walki z XSS, więc CSP rzeczywiście pełni rolę dodatkowej linii obrony. A jeśli aplikacja jest, nazwijmy to, "kreatywna", to stworzenie sensownej polityki nie jest zadaniem trywialnym (zakładając optymistycznie, że jest możliwe).

Kolejny slot, ten bolał mnie najbardziej - tutaj na odmianę trzy interesujące prezentacje:

• Outsmarting smart contracts - an essential walkthrough a blockchain security minefields - na tej byłem, bo ja już jestem wiekowy i dobrze dowiedzieć się coś więcej o tych nowinkach :)
• Case study of an XSS in Google's application including bypassing CSP - piękna kontynuacja wątku z dwóch wspominanych wcześniej prezentacji, niestety - coś musiałem wybrać :/
• Jailbreak - dylematy hazardzisty w pentestach aplikacji iOS - to jest coraz bardziej istotny temat. Kiedyś sprawa była stosunkowo prosta, miało się (co najmniej) dwa urządzenia, jedno "normalne", drugie po jailbreaku. Na początku wykonywało się kilka prostych testów na normalnym urządzeniu, choćby po to, by sprawdzić, czy testowana aplikacja działa, a potem już normalne testy z pełym dostępem. W czym problem? Coraz ciężej jest znaleźć jailbreak na nowe wersje iOS. Przy okazji temat do rozważań - czy to dlatego, że Apple tworzy tak bezpieczny kod, czy może raczej dlatego, że Chiny wolą zatrzymać takie rzeczy dla siebie.

Te prezentacje podobały mi się na pierwszym dniu Confidence. Nie mówię, że inne były słabe, po prostu te podobały mi się bardziej.

A 2018 practical guide to hacking RFID/NFC - w tym przypadku najbardziej zadziwia mnie to, że wciąż są rozwiązania, które opierają się w zasadzie wyłącznie na ograniczonej dostępności sprzętu i braku dokumentacji. Oparcie rozwiązania na statycznym UID i założeniu o braku możliwości spreparowania karty z określonym UID poza fabryką jest równie uzasadnione, jak oparcie bezpieczeństwa sieci LAN na adresie MAC. Przy okazji - trochę śmieszą mnie pytania czy NFC w iOS/Androidzie jest bezpieczne (w kontekście fizycznej kontroli dostępu). Akurat to, czy to NFC jest na karcie czy w telefonie jest mniej istotne w porównaniu z tym, co przez to NFC jest przesyłane.

How quantum computing is changing cryptography - naprawdę dobre i przystępne wyjaśnienie o co chodzi z tym całym quantum computing, jaki ma to wpływ na kryptografię asymetryczną i symetryczną, a także co z tym można zrobić. Przyznam się, że w tym zakresie mam wiedzę "użyteczną", czyli rozumiem o co chodzi, ale nie będę udawał, że w pełni rozumiem o co chodzi z tymi wszystkimi qubitami albo rozumiem wszystkie koncepcje używane / rozważane w kontekście post quantum crypto. Ta prezentacja dobrze systematyzuje temat, a poza tym pokazuje kilka tematów do zgłębienia (ciekawe na przykład jest to ile trzeba mieć qubitów by efektywnie mieć x qubitów; drugi ciekawy temat - jak zinterpretować wynik obliczeń komputera kwantowego).

Dwie dodatkowe punkty:

• Odnośnie wykorzystania kryptografii symetrycznej do podpisów - Hash-based Signatures: An illustrated Primer;
• Odnośnie NSA Suite B- Revisiting the NSA Suite B Announcement.

Pentesting Voice Biometrics Solutions - w tym obszarze mam dość ograniczone doświadczenia, więc całość była dla mnie interesująca. Do tego sama prezentacja to kawał solidnej roboty (zarówno pod względem formy i treści). Przy okazji - Kuba, złapałeś australijski akcent :P

Invoke-DOSfuscation: Techniques FOR %F IN (-style) DO (S-level CMD Obfuscation) - krótko mówiąc - magia. Ten temat bardzo fajnie pokazuje, że cmd.exe w Windows wcale nie jest tak prymitywny jak się powszechnie(?) uważa. Po drugie - to trochę zapomniana wiedza. Przynajmniej część technik (lub raczej możliwości) pokazanych w prezentacji była mi znana, ale nie myślałem o nich w kontekście obfuskacji. Podejrzewam, że spora część osób pracujących w obszarze szeroko pojętego security (akurat w tym kontekście patrzę głównie na SOC) doświadczenia z cmd.exe ma już znikome. Generalnie dodałem ten blog do swojej listy.

Chciałem wybrać się jeszcze na prezentację It's a trap! - Remote detection of low and medium interaction honeypots, ale wybrałem wybrałem prezentację Kuby, która odbywała się w tym samym czasie. Nie ukrywam, że niepomijalny wpływ na decyzję miały, nazwijmy to w ten sposób, warunki klimatyczne w namiocie, gdzie prezentacja Julio miała mieć miejsce. Obiecuję sobie jednak obejrzeć tę prezentację gdy nagrania zostaną opublikowane na stronie konferencji.