Wampiryczny blog

Święta są ZŁE!

2009-11-10T06:38:33-08:00

Nie lubię świąt. Radosne święto przypadające 1 listopada mamy już za sobą, skończyły się sprzedawać świeczki, więc pora na... Tak! Choinki, mikołaje, głupie czerwone czapki z pomponem, zestawy bombek szklanych (jedyne 24,95 PLN za 16 sztuk!) i inne świąteczne barachło.

Co mnie tak naszła świąteczna, radosna atmosfera? Raz na jakiś czas trzeba wybrać papierowy spam ze skrzynki. Jak myślicie, co w nim znalazłem? Skoro ja muszę cierpieć, to cierpcie razem ze mną :P

Pierwsza gazetka reklamowa (sklepu pierwszego), na pierwszej stronie mogę przeczytać, że zbliżają się święta.... Przypominam. Jest 10 listopada. Przyznam się, że musiałem sięgnąć do kalendarza (by się upewnić). Tak, rzeczone święta występują w dniach 25 i 26 grudnia wraz z 24 grudnia w roli "dnia przed". No ale przecież to już tak blisko! Na okładce mogę obejrzeć mikołaja, bombkę, skarpety przy kominku (zaiste bardzo polska tradycja), choinkę, prezenty, szczęśliwą metroseksualną rodzinkę pod choinką w głupich czerwonych czapkach, prezenty pod choinką i coś w rodzaju "wigilijnego" stołu. Zawartości środka opisywać mi się nawet nie chce.

Druga gazetka (sklepu drugiego), ponownie bombki, choinki, stroiki, świeczki, światełka, (...). I przy okazji informacje o dostępnych opcjach kredytowania, bo przecież wszystkie te produkty są absolutnie niezbędne do życia i szczęścia, a jak wygląda zawartość portfela dość sporej części społeczeństwa, chyba wiadomo. Ale w sam raz zakupy świąteczne się spłaci do marca/kwietnia tak by na kolejne święta można się było znów radośnie zadłużyć.

Kolejna gazetka (ponownie sklepu drugiego) wywiera na mnie presję, abym się gotował do świat. A wała!

Autorom tych i wszystkich przyszłych "świątecznotematycznych" gazetek mam do powiedzenia tylko tyle: oddalcie się ode mnie w podskokach, tanecznym krokiem na lekko ugiętych nogach. Szybko. Zanim się zrobię agresywny.

Ups. Za późno.

Zwykle swoje destrukcyjne zapędy wykorzystuję w trakcie testów aplikacji, tym razem zrobiłem wyjątek :)

Mój kubeczek to ile filiżanek?

2009-11-09T22:56:19-08:00

Herbata jest dobra na wszystko:

(...) Optymalna dzienna dawka kofeiny dla osoby dorosłej to 400 miligramów, czyli tyle, ile znajduje się w 8 filiżankach herbaty lub 4 kubkach kawy. (...)

No dobrze, to na dzień dobry przyjmuję 320 miligramów kofeiny (patrz: Green IT). W jednej filiżance herbaty znajduje się 50 miligramów (a tak przynajmniej wychodzi mi z prostego dzielenia). Czyli mogę wypić jeszcze 1,5 filiżanki herbaty. Super. Tylko ile filiżanek zawiera mój kubeczek?

Bootcamp XVII: hint I

2009-11-09T22:34:57-08:00

Moje drugie wyzwanie doczekało się pierwszej prawidłowej odpowiedzi. Tak naprawdę, to odpowiedź pojawiła się już 8 listopada, ale Sławek przesłał ją bezpośrednio do mnie, by nie psuć innym zabawy. Przygotował nawet skrypt, który w rozwiązaniu zadania pomaga, a który udostępnię za jakiś czas.

A teraz obiecany hint: tym razem przykład demonstruje w praktyce CWE-642: External Control of Critical State Data.

Bootcamp XVII: wyzwanie II

2009-11-07T11:09:30-08:00

Pod adresem http://bootcamp.threats.pl/lesson17/ znajduje się kolejny przygotowany przeze mnie w ramach bootcamp przykład. Tym razem jest to pewnego rodzaju wyzwanie.

Jest to prosty przykład aplikacji, która pozwala na logowanie użytkowników i, w zależności od uprawnień użytkownika (guest/user/admin), udostępnia użytkownikowi różne funkcje (formatki).

Przedmiotem wyzwania jest:

podglądnięcie danych innego użytkownika (formatka
Dane użytkownika),
eskalacja uprawnień,

Dodatkowo znaleźć można:

XSS,
brak kontroli dostępu do funkcji (tu - formatek),

Dane użytkownika z uprawnieniami gościa:

login: guest,
hasło: CicKiCinMirkakew,

Przyznam się, że nie do końca testowałem ten przykład, ale powinien działać i powinien robić to, co założyłem :)

Powodzenia!

Nie ma to jak sprawdzone chińskie wzorce

2009-11-06T07:19:00-08:00

Nic tak nie cieszy jak dobre informacje z rana: Koniec internetowej wolności w Polsce. Nie chodzi mi o ten konkretny przypadek, obejście ewentualnych ograniczeń nie będzie zbyt trudne, ale o trend, kierunek, w którym zmierza nasz "wolny świat".

Ludzie ciągle wierzą w bzdurne stwierdzenie "im więcej wolności, tym mniej bezpieczeństwa". Pojawiają się coraz to nowe pomysły "drobnych" ograniczeń wolności (lub/i prywatności), bo tak "będzie bezpieczniej". Co gorsza znajdują one poparcie w "społeczeństwie", bo temu "społeczeństwu" (przynajmniej znacznej jego części) jest tak wygodniej, wolą gdy ktoś myśli i podejmuje decyzje za nich.

Proponuję przeczytać artykuł Przeciw Prohibicji (Newsweek 45/2009), którego autorem jest Marcin Król, a z którego pozwolę sobie zacytować jedno zdanie:

Zapewne obywateli, którzy lubią rządy silnej ręki, zawsze będzie więcej niż radykalnych zwolenników wolności, gdyż zawsze więcej jest ludzi tchórzliwych niż odważnych.

Wyjątkowo trafne stwierdzenie.

Jak można przegapić DOM based XSS

2009-11-05T12:09:22-08:00

Jakiś czas temu na blogu Security Ninja pojawił się wpis Can you find the vulnerabilities?, teraz dostępne są rozwiązania zadań: Can you find the vulnerabilites? Part Two. Zadania są stosunkowo proste, ale jeśli ktoś jeszcze tego nie robił, proponuję spróbować się chwilę nad nimi zastanowić. Ja natomiast chciałem zwrócić uwagę na jeden konkretny przykład.

Fragment kodu, o którym mowa to:

var pos=document.URL.indexOf(”name=”)+5;
document.write(document.URL.substring(pos,document.URL.length));

Istnieje duża szansa, że w "tradycyjnych" testach z wykorzystaniem local proxy (np. Fiddler) podatność ta nie zostałaby wykryta. Przypominam, że testy takie polegają na modyfikowaniu parametrów przekazywanych do aplikacji i obserwowaniu tego, co aplikacja zwraca.

Dlaczego przypadek ten mógłby zostać pominięty? Dlatego, że aplikacja dla dowolnie różnych wartości parametru name może zwracać dokładnie taką samą treść. Skrypt natomiast pobierze wartość parametru z... no właśnie, skąd?

W przypadku wykorzystania local proxy żądanie wysyłane do serwera jest przechwytywane przez wykorzystane narzędzie, modyfikowane, a następnie wysyłane do serwera. Serwer widzi zmodyfikowane żądanie, przeglądarka generująca żądanie natomiast nic nie wie o wprowadzonych modyfikacjach. W tym przypadku parametr name jest przekazywany w GET, czyli jest częścią adresu URL. Skrypt osadzony na zwracanej stronie odwołuje się (w uproszczeniu) do przeglądarki, odczytuje adres URL i pobiera z niego oryginalną wartość parametru name. Nawet jeśli za pomocą proxy wartość parametru name zmieniliśmy, przykładowo, z Albercik na <script>alert(/XSS/);</script> to ten skrypt z przykładu nic o tym nie wie, wykorzysta oryginalną wartość parametru i wypisze jak gdyby nigdy nic Albercik.

Przykład ten pokazuje, że czasami warto popatrzeć również w kod skryptów działających po stronie klienta. Nie zawsze jest to łatwe, czasami ilość kodu JavaScript dołączanego do strony (aplikacji) jest naprawdę duża, czyli może nie wystarczyć czasu, a w dodatku kod jest "kompresowany", przez co kompletnie nieczytelny (w takich przypadkach korzystam zwykle z Malzilli, Fiddler ma z kolei plugin JavaScript Formatter, ale z niego nie korzystam)...

Tu jedno pytanie/temat do dyskusji - mając do dyspozycji ograniczony czas na czym (i dlaczego właśnie na tym) skupilibyście się? Na części "serwerowej" aplikacji, czy może na skryptach działających po stronie klienta, w przeglądarce?

Jankomuzykantyzm

2009-11-04T09:46:00-08:00

Był sobie uzdolniony muzycznie, ale chorowity chłopiec. Bardzo chciał sobie pograć na skrzypkach, a te znajdowały się w dworze. Zakrada się więc chłopak i... łapią go, posądzają o kradzież (...). Wiadomo jak to wszystko się skończyło. Później na lekcjach, przynajmniej za dawnych czasów, były rozważania co zrobiliby "państwo", gdyby wrócili wcześniej, jak to zaopiekowali się Jankiem i jaki wspaniały byłby z niego skrzypek.

Wczoraj zakończyła się sprawa o odszkodowanie dla rodziców zastrzelonego przez Policję motocyklisty. Miał chłopak pecha, znalazł się w nieodpowiednim czasie w nieodpowiednim miejscu, ale przede wszystkim usiłował uciec przed Policją i nie zatrzymał się do kontroli. Sąd uznał, że odszkodowanie się nie należy.

Kilka dni temu hakerzy (haker vs. cracker) włamali się na stronę UW, uczelnia sprawę zgłosiła prokuraturze. Podobnie jak w przypadku innych tego typu spraw, tak i tym razem rozległy się głosy typu: Wsadzajmy do więzienia ludzi za to że pokazują błędy w systemach komputerowych. Brak słów... albo (...), Uniwersytet zamiast składać doniesienie do prokuratury, powinien być wdzięczny hakerom, że pokazali jego władzom wadliwość zabezpieczeń.

I w tym właśnie momencie wkracza jankomuzykantyzm. Bo przecież to tacy zdolni młodzi(?) ludzie, a tu zły świat się na nich tak uwziął... Zamiast wdzięczności, kłody pod nogi... Główne argumenty "obrońców" są zwykle mniej więcej takie:

włamują się tylko po to, by pokazać, że można,
robią to w celach edukacyjnych,
nikomu nie dzieje się krzywda,

Warto zastanowić się, czy rzeczywiście nikomu nie dzieje się krzywda. Utrata wizerunku, utrata zaufania (potencjalnych) klientów, koszty poniesione na odtworzenie działania aplikacji. Zdecydowanie nie jest to "nic", więc twierdzenie, że "nikomu nie dzieje się krzywda" jest oderwane od rzeczywistości. Wcale się nie dziwię, że "uszczęśliwieni" niechcianą usługą wcale nie są nią zachwyceni i decydują się na złożenie wniosku o ściganie przestępstwa, do czego mają pełne prawo. Z dostępnych informacji dotyczących zdarzenia wynika, że przestępstwo prawdopodobnie zostało popełnione, ale decyzja w tej sprawie należy do prokuratury i sądu. Można również dyskutować, czy można ominąć zabezpieczenia, których nie ma, ale to zupełnie inna kwestia.

Pokazanie, że aplikacja jest podatna wcale nie musi zawierać w sobie umieszczania "charakterystycznych wpisów" oraz informowania mediów o całej sprawie. Podejrzewam, że uczelnia zareagowałaby inaczej, gdyby została o problemie poinformowana w nieco bardziej cywilizowany sposób. Pewności w tym względzie mieć jednak nie można, więc we własnym interesie lepiej trochę uważać, bo konsekwencje takiej "edukacji" mogą być dość nieprzyjemne. Może nie w tak gwałtowny sposób jak, przykładowo, domowe zabawy "edukacyjne" z niewybuchami, ale jednak uciążliwe.

"Edukować się" można na wiele sposobów, poczynając od wykorzystania aplikacji typu OWASP WebGoat, różnych hackme (tu wspomnę o moim przewodniku po podstawach bezpieczeństwa aplikacji internetowych), a na testowaniu dostępnych aplikacji (co za problem zainstalować sobie WordPress, Drupal, Xyz, FooShmu, ... albo skorzystać z moth) kończąc.

W kodeksie karnym istnieją (między innymi) dwa artykuły: 267 i 268, o których warto pamiętać. W obu przypadkach ściganie przestępstwa następuje w wyniku wniosku pokrzywdzonego. Trzeba po prostu przyjąć do wiadomości, że "pokazywanie wadliwości zabezpieczeń" bez wiedzy i zgody zainteresowanego (właściciela) może skończyć się ograniczeniem wolności do lat dwóch/trzech/(...), w zależności od tego, pod jakie paragrafy zostanie to ostatecznie podciągnięte. Do tego można jeszcze dodać ewentualne problemy z zatrudnieniem tam, gdzie wymagane jest zaświadczenie o niekaralności, przynajmniej do czasu zatarcia skazania. Trzeba znać potencjalne konsekwencje swoich czynów. Nie ważne czy jest to ucieczka przed Policją (pechowo w czasie obławy), czy "tylko" edukacyjne włamanie na serwer, które, zgodnie z obowiązującym prawem, jest przestępstwem.

A jeśli ktoś dysponuje zbyt dużą ilością wolnego czasu i bardzo chce pokazać, że można, to proszę bardzo, ma okazję: Live Labs Web Sandbox.

Na zakończenie spojrzenie z nieco innej strony - nie można zakładać, że jakiekolwiek przepisy powstrzymają "prawdziwych" włamywaczy, w związku z czym aplikacje i systemy powinny być bezpieczne. Przynajmniej tak bezpieczne, by potencjalni intruzi znaleźli sobie inne, łatwiejsze obiekty ataku.

Konkurs 2.0

2009-11-03T22:24:18-08:00

Z okazji pierwszego w tym roku Confidence odbył się konkurs CONFidence Security Evangelist. Wygląda na to, że z okazji kolejnej edycji Confidence jest również kolejna edycja konkursu.

Bootcamp XVI: jeszcze jedno zadanie

2009-11-02T22:27:54-08:00

Tak sobie pomyślałem, że (prawie) rozwiązany wczoraj przykład można wykorzystać jeszcze do jednego zadania: korzystając z istniejącego w przykładzie XSS osadzić skrypt z innej strony. Przydatny może być XSS Cheat Sheet.

Bootcamp XVI: rozwiązanie

2009-11-02T11:06:00-08:00

Radekk jest pierwszą osobą, która rozwiązała najnowsze zadanie na bootcamp. Przy okazji dołączył do bardzo nielicznego grona osób, które poradziły sobie z wyzwaniem (swoją drogą zapraszam, dostępnych jest kilka wskazówek). Tym razem również nie podam dokładnego opisu rozwiązania, zarówno XSS (w ramach inspiracji: JS Ninja) jak i SQLi (jeśli ktoś potrzebuje pomocy: Lekcja 7: (blind) SQL injection) nie są wyjątkowo interesujące. W przykładzie tym ważne jest coś innego...

Podałem trzy podpowiedzi do zadania:

skąd serwer "wie", jak nazywa się przekazywany plik,
"co z tego, że tak nie można nazwać pliku?",
trust boundary,

Na pierwsze pytanie łatwo odpowiedzieć patrząc na wysyłane przez przeglądarkę żądanie:

Nazwa (czasami również cała ścieżka) przekazywanego pliku zawarta jest w atrybucie filename, który ustawiany jest przez przeglądarkę na podstawie nazwy (ścieżki) wskazanego pliku. Praktycznie każdy system plików narzuca pewne ograniczenia odnośnie nazwy pliku, a i system operacyjny nie jest tu bez znaczenia. Ogólnie rzecz biorąc nazwa pliku nie może być dowolna.

Dwie kolejne podpowiedzi łączą się w zasadzie w jeden scenariusz: wartość atrybutu filename w żądaniu wysyłanym przez przeglądarkę może zostać dowolnie zmodyfikowana przez atakującego. Nowej nazwy pliku prawie nie dotyczą żadne z ograniczeń, które "wymusza" system operacyjny czy system plików. Innymi słowy jeśli ktoś oczekuje, że nazwa pliku nie będzie zawierała znaków typu < czy > tylko dlatego, że nie można utworzyć pliku o takiej nazwie, to jest w błędzie.

Przy okazji warto zauważyć, że w analogiczny sposób w jaki można zmienić "nazwę pliku", można zmienić również jego "typ". Typ (w sensie typu MIME) pliku przekazywany jest w atrybucie Content-Type i, podobnie jak filename, może zostać dowolnie zmodyfikowany przez atakującego. A co z tego wynika, łatwo można się domyślić.

Na zakończenie przypomnę jeszcze raz o wpisie File upload security recommendations. Warto zapoznać się z tymi zaleceniami i je stosować.

Dziwny zbieg okoliczności

2009-11-02T03:09:51-08:00

Dziś można przeczytać, że Polak w pracy - wynosi sprzęt, kradnie towar, oszukuje... I w sumie nie dziwi mnie to, ale zastanawiam się jaki związek ma opublikowanie wspominanego raportu przez firmę Euler Hermes z lekko irytującymi reklamami ubezpieczenia ryzyka sprzeniewierzenia oferowanego przez wspomnianą firmę. Budzi się we mnie "drobna niewiara" w wyniki badania, jeśli firma będąca jego autorem jest równocześnie żywotnie zainteresowana sprzedażą swoich produktów, których to sprzedaż będzie tym wyższa, im bardziej mroczne wizje będą kreślone...

Bootcamp XVI: hinty

2009-10-31T05:50:46-07:00

Ja wiem, że nie jest to może najbardziej pasjonujące wyzwanie, ale ponieważ kilka razy z takimi błędami spotkałem się na wolności, zwracam uwagę na jedno zagadnienie: skąd serwer "wie", jak nazywa się przekazywany plik?

No właśnie, skąd?

Drugi hint jest zawarty w tytule pierwszego posta: co z tego, że tak nie można nazwać pliku?

Trzeci hint: trust boundary.

Bootcamp XVI: co z tego, że tak nie można nazwać pliku?

2009-10-29T00:02:37-07:00

W ramach porannej rozrywki: http://bootcamp.threats.pl/lesson16/. Chodzi o XSS i SQLi.

O wyciąganiu (błędnych) wniosków

2009-10-27T12:19:00-07:00

Trzeba wyciągać wnioski, z tego, co się już wie. Sam tak uczyłem się jeździć na rolkach (bez ochraniaczy). Po dwóch bliskich spotkaniach z podłożem wyciągnąłem prosty wniosek - to boli. Był on może niezbyt błyskotliwy, ale motywował mnie bardzo skutecznie do tego, by raz popełnionych błędów nie powtórzyć w przyszłości. Ta metoda nauki zadziałała w moim przypadku bardzo dobrze, obyło się bez złamań, choć kilka efektownych spotkań z ziemią jeszcze udało mi się zaliczyć :) Tak samo w drugą stronę, jeśli jakieś działanie osiągnie pożądany skutek, należy je powtarzać (co oczywiście nie wyklucza poszukiwania lepszych rozwiązań). Ten wzorzec postępowania wpaja się nam, przedstawicielom homo sapiens, od najmłodszych lat. Stosujemy go nawet tam, gdzie nie do końca pasuje. Dziś kilka słów o wyciąganiu błędnych wniosków, a właściwie czynieniu błędnych założeń, w trakcie testów bezpieczeństwa aplikacji.

Czasami mam wrażenie, że programiści są wiernymi uczniami Sun Tzu, szczególnie w zakresie nauki o konieczności zaskoczenia przeciwnika i działaniach niekonwencjonalnych. O co chodzi? O to, że bardzo często aplikacje są niespójne. Nie wynika to oczywiście z tego, że złośliwi programiści w przypływie dobrego (czarnego?) humoru postanowili o czymś "zapomnieć" lub w tym-jednym-przypadku zrobić coś inaczej, niż wszędzie do tej pory. Powody są bardziej trywialne, na przykład:

programistów jest wielu, mają różne umiejętności, te same rzeczy robią w różny sposób,
aplikacje nie stają się lecz są rozwijane, często przez dłuższy czas i różnych programistów,
korzystający ze sprawdzonego wzorca projektowego copy-and-paste, kopiowali z różnych źródeł,
programiści działają pod presją czasu i by zdążyć na czas, idą na skróty,
(...),

Im aplikacja jest większa i starsza, tym większe jest prawdopodobieństwo, że będzie ona w rzeczywistości patchworkiem różnych technologii, frameworków, wzorców projektowych i błędów... Refaktoring systemu wciąż czeka na lepsze czasy. W skrajnych dwa parametry tego samego typu na tej samej formatce mogą być obsługiwane w zupełnie inny sposób, przez co wnioski wyciągnięte przy testowaniu parametru A mogą nie być prawdziwe dla sąsiedniego parametru B...

W tej chwili przypomina mi się pewien cytat:

Mamy znane wiadome. Rzeczy, o których wiemy, że je wiemy. Wiemy również, że istnieją znane niewiadome. Innymi słowy, wiemy, że są pewne rzeczy, których nie wiemy. Ale są również nieznane niewiadome – takie, o których nie wiemy, że ich nie wiemy.

Sytuacja, w której aplikacja jest w oczywisty sposób niespójna jest oczywiście zła i sama w sobie może być przesłanką co do prawdopodobieństwa istnienia w niej podatności lub wystąpienia ich w przyszłości. Niewątpliwą zaletą jest fakt, że jest to swoista znana niewiadoma. Wiemy, że aplikacja jest niespójna, więc nie możemy robić żadnych założeń w oparciu o dotychczasowe wyniki testów.

Dużo gorszą sytuacją jest przypadek, w którym nie wiemy (jeszcze) o tym, że aplikacja jest niespójna. Jesteśmy nawet przekonani, że jest wprost przeciwnie (do do tej pory jest/była spójna). To ten przypadek, w którym nie wiemy, że nie wiemy. Jeśli na 15 formatkach wszystkie wystąpienia pola określonego typu (np. daty) były poprawnie walidowane, to w kolejnych przypadkach sprawdza się to już wyrywkowo (redukcja przypadków testowych), aż trafia się na wyjątek rzekomo potwierdzający regułę... Albo co gorsza - nie trafia się (pół biedy), ale trafia na ten przypadek ktoś inny (cała bieda).

W tej chwili warto zastanowić się chwilę nad OWASP Application Security Verification Standard, na przykład nad takim punktem:

V5.2 Verify that a positive validation pattern is defined and applied to all input.

Jak należy rozumieć w tym przypadku all? Z jednej strony wystarczy wskazać jeden przypadek, w którym takiej walidacji nie ma by stwierdzić, że aplikacja nie spełnia tego wymagania, z drugiej strony stwierdzenie, że aplikacja spełnia ten warunek wymaga, przynajmniej w teorii, sprawdzenia każdego parametru, który przez aplikację jest akceptowany.

Osiągnięcie pełnego pokrycia aplikacji takimi testami jest możliwe, ale wraz ze wzrostem złożoności aplikacji coraz trudniejsze i, co tu dużo mówić, droższe. Ciekawym tematem może być kwestia wyboru odpowiedniej próby reprezentatywnej parametrów, na badania podstawie której, z odpowiednim/założonym prawdopodobieństwem, można wnioskować o bezpieczeństwie badanej aplikacji (przy okazji zwracam uwagę, że przy analizie ryzyka uwzględnia się nie tylko co może się stać i jak bardzo ZŁE to jest oraz z jakim prawdopodobieństwem może się to stać, ale również to, jak pewne są odpowiedzi na poprzednie dwa pytania).

Macie jakieś pomysły/propozycje w tym temacie? Czy jest to możliwe bez wcześniejszego "ujednolicenia" aplikacji?

"Walka stulecia"

2009-10-25T12:45:00-07:00

Gdyby traktował określenie walka stulecia poważnie i był fanem/kibicem boksu, to chyba bym się załamał. Poziomem walki oczywiście. A może nie tyle poziomem, co tym, że coś takiego może być określane walką stulecia właśnie. Całe wydarzenie należy raczej rozpatrywać jako udany skok na kasę organizatorów "gali bokserskiej" oraz dowód na to, jak łatwo (obecnie) manipulować ludźmi.

Po pierwsze - trzeba znaleźć chwytliwą nazwę. Walka stulecia brzmi dobrze, w końcu przeciętny czas życia człowieka jest wciąż mniejszy niż 100 lat, tak więc jeśli traktować owo określenie dosłownie, należy przyjąć, że oglądający tak określaną walkę są świadkami wydarzenia unikalnego. Każdy chce być świadkiem wyjątkowych wydarzeń, a tu tak niewiele do tego potrzeba, wystarczy kupić bilet albo włączyć telewizor. Nagle (bierni) uczestnicy stają się elitą.

Skoro wymyślona została już nazwa, trzeba ją odpowiednio zagnieździć w świadomości pospólstwa. Bo spójrzmy prawdzie w oczy, jak może wyglądać starcie młodego boksera, który dysponuje dość przeciętnymi warunkami fizycznymi, jak na wagę ciężką, ale jest szybki z wielkim (wysokim) i ciężkim emerytem, który lata swej świetności ma dawno za sobą? Niech zgadnę - młody będzie okładał emeryta ile wlezie, a emeryt będzie liczył na to, że młody się odsłoni i uda mu się sprzedać jeden lub dwa mocne ciosy... Moment, przecież dokładnie tak wyglądała ta walka! I tak jestem pod wielkim wrażeniem, że Gołota dotrwał aż do 5 rundy...

Kolejnym krokiem musiało być oczywiście utrzymanie zainteresowania wydarzeniem, dzień bez wiadomości o przygotowaniach dniem straconym. W szczególności trzeba podkreślać dobre przygotowanie Gołoty, choć z drugiej strony nie można zapomnieć o pikantnych wstawkach, a to o brązowych getrach, a to o historii, w której rzekomo Gołota odpowiedział "po naszemu" na pytanie, czy chce walczyć (znaczy się nooooo), co wredny sędzia bez odpowiedniego przygotowania językowego miał uznać za odmowę dalszej walki... A tak! Nie zapomnijmy jeszcze o osobistych animozjach. Niech to będzie sprawa osobista, to na pewno wzbudzi większe emocje!

I w końcu przyszedł ten wielki dzień, dzień walki, jaka zdarza się raz na 100 lat. Na galę ściągnęli licznie wątpliwej jakości celebryci (fascynuje mnie to określenie, powinniśmy używać polskiego terminu: wioskowy głupek, w większości przypadków pasuje jak ulał), wiecznie młody Ibisz zapowiadał walkę basem (ciekawe czy własnym, czy korzystał z dobrodziejstw techniki) i zaczęło się... a chwilę później skończyło. Ale nic to, bilety - sprzedane, reklamy - sprzedane. Potencjalne zyski za transmisje z walk Adamka zwiększone, wszak będzie to ten Adamek, który pokonał Gołotę, a i okazało się, że być może również Gołota jeszcze jedną tym-razem-już-na-pewno-ostatnią jeszcze stoczy... A w tak zwanym międzyczasie jeszcze ma mieć miejsce jedna walka: Pudzianowski vs. Najman.

Jedno wyjaśnienie - walkę stulecia oglądałem wyłącznie w celach rozrywkowych i tylko dlatego, że miałem telewizor pod ręką, którego nie posiadam i z czego się cieszę (z nieposiadania telewizora oczywiście, a nie z tego, że miałem okazję to coś oglądać).