Tak, Mikko Hypponen i jego State of The Net zgodnie z (moimi) oczekiwaniami dał radę. Z Mikko jest tak, że choć w zasadzie dobrze wiadomo co będzie mówił, to opowiada to w taki sposób, że zainteresuje słuchacza i dokładnie tak było na CONFidence. Pod względem “efekciarstwa” – podobało mi się gasnące światło, choć też widziałem to nie pierwszy raz w jego wykonaniu: Mikko Hypponen: Fighting viruses, defending the net.
Czego mi brakowało – tego selfie z mainframe :)
P.S: Spiskowa teoria dziejów – Mikko wspomniał, że F-Secure wprowadził do oferty pentesty i udało im się osiągnąć założone cele w każdym ze zleceń. Pytanie – z jakiego oprogramowania antywirusowego/zabezpieczającego korzystały testowane firmy? F-Secure? :)
Chodzi mi o tę prezentację: Wordlists: from statistics to genetic. W skrócie – wykorzystanie algorytmów genetycznych do stworzenia słownika (kombinacji istniejących słowników), który jest “lepszy”. Ta “lepszość” słownika ma przejawiać się większą skutecznością przy mniejszym rozmiarze, a więc i czasie łamania hashy haseł.
O ile sam temat i zastosowanie podejście jest ciekawe, mam pewien problem z implementacją. Pytanie – względem czego była sprawdzana skuteczność słowników? Z odpowiedzi udzielonej przez prowadzącego – skuteczność słownika była ewaluowana na hasłach (hashe), które można znaleźć w sieci (wyniki wycieków).
Super. A na jakiej podstawie tworzone są słowniki? Czy przypadkiem nie na podstawie tych samych wycieków i haseł, które udało się złamać?
O co mi chodzi? Z prezentacji wynika, że “mutacje” odbywały się na poziomie całego słownika (docelowy słownik składał się z N słowników, np. 500 worst passwords , rockyou , (...)). Co z tego wynika? Jeśli jako materiał testowy wykorzystane są hashe z wycieku X siłą rzeczy najlepsze będą te kombinacje słowników, które zawierają listy powstałe na podstawie tego wycieku. Dlaczego? Dlatego, że standardowym podejściem przy łamaniu hashy z wycieku X jest wykorzystanie (wszystkich) dostępnych słowników. W efekcie nowa lista jest najbardziej efektywna dla tej populacji hashy.
Podsumowując – ciekawszym podejściem byłoby użycie jako danych testowych/referencyjnych populacji hashy, które na pewno nie były użyte do stworzenia słowników użytych w eksperymencie. Najlepiej dwóch takich populacji – jednej w trakcie “ewolucji” słowników, a drugiej – do sprawdzenia skuteczności otrzymanego słownika. Bardzo jestem ciekawy wyników tego porównania.
Ten blog ma już 10 lat... Nie będzie wspomnień, podsumowań, (...). Ot tak, z ciekawości kiedyś zajrzałem na datę pierwszego wpisu i trochę się zdziwiłem, że to już taki szmat czasu.
Oryginał tego wpisu dostępny jest pod adresem 10 lat
To jest pytanie, nie odpowiedź. Generalny scenariusz – payload XSS można podzielić na dwie części: “loader” i “payload właściwy”. Zamiast zwyczajowego alert(0) do potwierdzenia, że XSS jest rzeczywiście exploitowalny można wstrzyknąć działający loader, który załaduje PoC z zewnętrznego serwera. Taki scenariusz pozwala pokazać, że ewentualne kontrole dodatkowe / kompensacyjne (np. WAF, CSP) nie działają.
Mam taką małą zagadkę – od kilku dni serwer zwraca niektóre pliki ze złym Content-Type a do tego w przypadku kilku plików (statycznych) serwer zwraca błąd 500. Ciekawe, jak będę miał więcej czasu (święte nigdy) to przyjrzę się temu dokładniej.
Oryginał tego wpisu dostępny jest pod adresem Zagadka
“Nie lubię” to może trochę za mocno powiedziane. Generalnie chodzi o konfrontację wspomnień (wyobrażeń) z bieżącą rzeczywistością , która często skrzeczy (dosłownie). Przykład: Paradise City. I dla porównania wersja '92 oraz wersja płytowa. Jeśli trzymamy się wersji koncertowych – te (prawie) 25 robi zauważalną różnicę...
Bank, z którego korzystam, postanowił “uprościć” sposób parowania/aktywacji aplikacji mobilnej. Wcześniej proces wyglądał standardowo:
Skanowanie kodu QR w bankowości internetowej;
Podanie kodu SMS potwierdzającego parowanie;
Podanie kodu wygenerowanego przez aplikację (pod spodem był OTP).
Teraz jest lepiej:
W aplikacji mobilnej podaje się login i numer dowodu;
Generuje się kod parujący (przekazany telefonicznie, automat);
....
No właśnie, nie wiem co dalej, bo utknąłem na tym etapie. Rzeczywiście, dzwoni do mnie automat, radośnie informuje mnie, że zaraz usłyszę mój kod parowania (hura!), ale by go usłyszeć muszę nacisnąć “1”. Naciskam “1” i... połączenie zostaje przerwane. Do tego należy dodać jedną, jakże mało istotną informację – jest limit jednej próby aktywacji na 24 godziny.
Efekt – nadal nie jestem w stanie aktywować aplikacji mobilnej na drugim urządzeniu. Ale przecież jest łatwiej, prawda?
Kilka tygodni temu rozmawialiśmy z kolegą (pentester, expat) na temat polskich konferencji, na których warto być. W takiej dyskusji nie można było pominąć CONFidence. Wtedy na temat tegorocznej edycji było dziwnie cicho. Okazuje się jednak, że i w tym roku CONFidence nie zabraknie. Tym razem konferencja odbędzie się w dniach 19 i 20 maja, ponownie w Hotelu Forum. Więcej szczegółów tutaj.
Ostatnio w swojej skrzynce znalazłem kilka zaproszeń na kilka wydarzeń, między innymi na KrakYourNet7, KrakWhiteHat czy Warszawskie Dni Informatyki. Za wszystkie te zaproszenia bardzo dziękuję, ale niestety nie jestem w tej chwili znaleźć czasu by z nich skorzystać. Skorzystać, czyli przygotować interesującą prezentację, która da coś uczestnikom.
Nie, nie mam w zwyczaju jeździć z tą samą prezentacją na różne konferencje, prawie zawsze przygotowuję coś nowego. Jedynym większym wyjątkiem od tej reguły była prezentacja z Confidence 2014, która później trafiła również na WHEEL Evening #006. Nie mam również w zwyczaju przygotowywać prezentacji w ostatniej chwili (np. w pociągu jadąc już na konferencję); uważam, że jeśli ktoś mnie zaprasza, a ja decyduję się wystąpić, to należy dostarczyć dobry “produkt”. Podziwiam osoby, które w takim trybie potrafią przygotować coś ciekawego/wartościowego (jest takich osób kilka), ale ja (sam) się do nich nie zaliczam. Potrzebuję więcej czasu, którego teraz po prostu nie mam...
Oryginał tego wpisu dostępny jest pod adresem Nie mam czasu
