Proof-of-work
Jakiś czas temu pisałem o sposobie na limitowanie liczby żądań generowanych przez klienta: Limitowanie klienta. Chcę na chwilę wrócić do tego tematu w kontekście ochrony przed DoS.
Jakiś czas temu pisałem o sposobie na limitowanie liczby żądań generowanych przez klienta: Limitowanie klienta. Chcę na chwilę wrócić do tego tematu w kontekście ochrony przed DoS.
Ostatnio dowiedziałem się o istnieniu PunkSPIDER. Co to jest? Cytując za About PunkSPIDER:
PunkSPIDER is a global web application vulnerability search engine powered by PunkSCAN. What that means is that we have built a scanner and architecture that can handle a massive number of web application vulnerability scans, set it loose on the Internet, and made the results available to you. It runs off of an Apache Hadoop cluster and is able to handle tens of thousands of scans every day.
Tak się składa, że jedna z moich stron znajduje się w tej bazie:
Timestamp: Fri Nov 23 12:11:58 GMT 2012
BSQLI:0 | SQLI:0 | XSS:0
Cóż, aż prosi się by zajrzeć w logi i zobaczyć jak wyglądał proces skanowania. Niestety, w logach udało mi się znaleźć jedynie to:
198.101.171.18 – – [23/Nov/2012:13:08:38 +0100] “GET /robots.txt HTTP/1.0” 200 194 “” “Punk Spider/PunkSPIDER-v1.0.0” 198.101.171.18 – – [23/Nov/2012:13:08:38 +0100] “GET / HTTP/1.0” 200 3647 “” “Punk Spider/PunkSPIDER-v1.0.0”
Ktoś inny znalazł się w bazie? Może znalezione zostały jakieś podatności? Ktoś się podzieli?
Sam kod użytego narzędzia dostępny jest tutaj: PunkScan.
P.S. Warto monitorować rezultaty tej “wyszukiwarki”. Jeśli przypadkiem coś znajdzie i przypadkiem nie będzie to false positive, to lepiej się o tym dowiedzieć, zanim dowiedzą się ONI. Jakoś nie wierzę, że prośba Please do not use this site for malicious purposes (popup po wejściu na stronę) spotka się ze zrozumieniem...
Oryginał tego wpisu dostępny jest pod adresem PunkSPIDER
Autor: Paweł Goleń
Po przerwie powrót do tematu poruszanego w poprzednich wpisach. Jednym z warunków zadania była wymagana unikalność identyfikatora na przestrzeni 10 lat. Dodatkowo wiedzieliśmy, że w ciągu sekundy będzie (w przybliżeniu) generowany jeden identyfikator. Oznacza to, że w ciągu 10 lat będzie ponad 315360000. Dla uproszczenia załóżmy, że będzie ich około 316224000 (to wtedy, gdyby każdy rok liczył 366 dni).
Uwaga, uwaga. Security B-sides Kraków. Oczywiście Kraków, 2 i 3 marca, a więc już wkrótce.
Wedługobecnej wersji agendy, na dzień dobry – ja :)
Zapraszam wszystkich zainteresowanych. Edycję warszawską wspominam bardzo pozytywnie, mimo dość spartańskich warunków :)
EDIT:
Wygląda na to, że jednak się pospieszyłem z zapowiedzią:
Z przyczyn technicznych jestesmy zmuszeni przesunac termin konferencji. Rozpoczynamy prace nad nowym terminem.
Patrz: Nowy termin – do ustalenia
Oryginał tego wpisu dostępny jest pod adresem Security B-sides Kraków 2013
Autor: Paweł Goleń
Mózg to fascynujące ustrojstwo. Czasami zastanawiam się, czy to ja posiadam mózg, czy mój mózg posiada mnie. Na przykład lubi wybrać sobie temat, nad którym postanowi sobie pracować, kompletnie ignorując przy tym fakt, że pora bardziej odpowiednia do snu, niż do myślenia. Mogę albo usiłować spać (czyli wiercić się przez najbliższą godzinę), albo temat pokonać. Przy okazji temat jest odrobinę związany z poprzednią zagadką, więc będę miał mniejsze wyrzuty sumienia związane z chwilowym brakiem kontynuacji tematu.
Widzę, że moja zagadka nie spotkała się z wielkim zainteresowaniem. No ale cóż, to mój blog i mogę na nim pisać o tak nudnych tematach, na jakie mam tylko ochotę. Zwłaszcza, że temat jest ciekawy i ma praktyczne zastosowanie dla ludzi z obu stron barykady.
Kilka pytań naprowadzających:
Pytania pomocnicze:
Oryginał tego wpisu dostępny jest pod adresem Zagadka: ciąg dalszy
Autor: Paweł Goleń
Załóżmy, że w aplikacji identyfikatory przyznawane wszystkim obiektom generowane są przez następujący kod:
def randomidgenerator(): starttimestamp = 1356994800 while True: currenttimestamp = int(time.time()) timestamp = (currenttimestamp – starttimestamp) / 60 r = struct.unpack(“B”, os.urandom(1))[0] << 24 yield struct.pack(“L”,(r ^ timestamp)).encode(“hex”)
Założenie jest takie, że przyznawane identyfikatory nie powinny być sekwencyjne, tak by enumeracja obiektów z użyciem bezpośredniego użycia identyfikatora była nieefektywna. Przewiduje się generowanie nie więcej niż jednego identyfikatora na sekundę. Identyfikatory muszą pozostać unikalne przez okres 10 lat.
Pytanie – ile widzicie błędów w tym podejściu?
Oryginał tego wpisu dostępny jest pod adresem Zagadka: co jest tutaj źle?
Autor: Paweł Goleń
Na początek zagadka. Co jest nie tak z tym kodem (Python):
import random osoby = ['osoba1', 'osoba2', 'osoba3'] print osoby[random.randint(0,10)%25len(osoby)]
Okazało się, że w czasie ostatniej ślizgawicy ucierpiała nie tylko moja dup^wduma, ale również taki mój jeden gadżet:

Nie widać tego dokładnie na zdjęciu, ale elektronika jest uszkodzona, w szczególności kość pamięci pokryła się ładną siatką pęknięć.
Nie był to najbardziej pojemny pendrive, szybkością również nie grzeszył. Miał natomiast jedną cechę, którą bardzo lubiłem – po podłączeniu do komputera przedstawiał się jako dysk, a nie jako nośnik wymienny. Co z tego? To, że wówczas można było na nim zrobić partycje (specyfika Windows), jedną zostawić nieszyfrowaną i trzymać na niej niezbędny toolbox, a drugą zaszyfrować w całości TrueCryptem i trzymać na niej notatki z testów.
Zna ktoś może jakieś powszechnie dostępne gadżety, które mają taką samą cechę?
Oryginał tego wpisu dostępny jest pod adresem Buuuu :(
Autor: Paweł Goleń
Prosty eksperyment:
Właściwie do ostatniego punktu może się nie uda dojść, bo samo zamontowanie kontenera może okazać się niemożliwe (właściwie – otwarcie zamontowanego kontenera).