Paweł Goleń, blog

Challenge without an interesting name.

Oryginał tego wpisu dostępny jest pod adresem No i wyknułem

Autor: Paweł Goleń

Tak, knuję. Mianowicie nad tym, by przygotować pewnego rodzaju challenge. Koncepcja mam taką, by kolejne etapy były udostępniane w ramach zaszyfrowanego kontenera TrueCrypt. By dostać hasło do poziomu n+1 trzeba będzie rozwiązać poziom n. Zadania będą różne, nie tylko aplikacje webowe. Myślę, że zabawa ruszy, jak będę miał gotowych co najmniej 5 zadań.

Oryginał tego wpisu dostępny jest pod adresem Knuję

Autor: Paweł Goleń

Czasami zastanawiam się intensywnie nad sensownością szyfrowania danych, nawet jeśli klucz użyty do szyfrowania tych danych jest potencjalnie łatwy do ustalenia (czyli właściwie bardziej obfuskacja niż szyfrowanie). Już wyjaśniam o co mi chodzi.

Załóżmy, że tworzę serwis podobny w koncepcji do Pastebin. Nie ma on służyć do przekazywania szczególnie istotnych danych, ale chciałbym ograniczyć prawdopodobieństwo masowego ich ujawnienia. Załóżmy, że:

• w bazie danych przechowywana jest tylko “metryczka” wklejki,
• same wklejki przechowywane są jako pliki na dysku,

Nagle okazuje się, że z jakiegoś powodu mamy do czynienia z klasycznym głębokim ukryciem i wszystkie pliki zawierające wklejki stają się publicznie dostępne...

Załóżmy teraz, że każdy z tych plików jest szyfrowany, a klucz szyfrowania jest generowany np. w oparciu o:

• identyfikator pliku,
• losowy salt przechowywany w metryczce pliku,
• sekret zawarty w (konfiguracji) aplikacji,

Jeśli ktoś przejmie pełną kontrolę nad serwerem, będzie on oczywiście w stanie odszyfrować każdy plik, jeśli jednak mamy do czynienia wyłącznie z “głębokim ukryciem”, to jego szczęśliwi odkrywcy nie bardzo będą mieli się czym chwalić.

Zastanawiam się też nad podobnym podejściem w przypadku części danych przechowywanych w bazach SQL. Wówczas klucz mógłby być unikalny dla użytkownika, ładowany przy jego uwierzytelnieniu i wykorzystywany przy odczycie/zapisie pewnych danych. Mogłoby to chronić do pewnego stopnia przed skutkami SQLi czy błędami kontroli dostępu – atakujący nie otrzymałby danych innego użytkownika, ponieważ nie dysponowałby odpowiednim kluczem. Co więcej, jeśli byłby wykorzystany tryb szyfrowania z kontrolą integralności (authenticated encryption), w bonusie dostalibyśmy wykrywanie próby dostępu do cudzych danych.

Tu warto też wspomnieć o szyfrowaniu homomorficznym, ale to już trochę wyższa szkoła jazdy.

Oryginał tego wpisu dostępny jest pod adresem A może jednak szyfrować?

Autor: Paweł Goleń

Jeśli szukacie jakiegoś podcastu do posłuchania, możecie rzucić uchem na ISC Monthly Threat Update – February 2012. Może nie jest on specjalnie porywający, ale warto zwrócić uwagę na temat, który pojawia się (na krótko) mniej więcej między 7:45 i 9:50. Johannes mówi tam o asymetrii między obrońcami i atakującymi.

Jeśli atakujący ma skuteczność na poziomie 1%25 (na 100 parametrów podatnych na SQLi przegapi 99 z nich), to i tak odniesie sukces. Jeśli natomiast obrońca ma skuteczność na poziomie 99.9%25 (na 1000 parametrów podatnych na SQLi przegapi 1), to i tak ktoś może znaleźć ten jeden parametr i skutecznie wyprowadzić dane.

Między innymi na temat tej asymetrii (dysproporcji) pisałem już dawno temu: Pentester: doomed to fail?. Ciekawym pomysłem na zmniejszenie tej dysproporcji są programy typu bug bounty. Ludzie i tak szukają błędów, lepiej więc, jeśli znalezione błędy raportują bezpośrednio do dostawcy, a nie “puszczają w obieg”. Dzięki temu firma, która taki program ogłasza, zyskuje za niewielkie pieniądze rzeszę testerów, a w bonusie – pozytywny PR.

Oryginał tego wpisu dostępny jest pod adresem Asymetria

Autor: Paweł Goleń

Pora na kilka wskazówek do przykładu z bootcamp. A więc po kolei:

• nie, nie chodzi o przeszukanie przestrzeni identyfikatorów (jest znany: 2161),
• jak aplikacja zachowuje się przy próbach SQLi (patrz: Bootcamp #5: Jak szukać SQLi #1, Bootcamp #6: Jak szukać SQLi #2),
• czy działają operacje arytmetyczne,
• co jest przekazywane w parametrze p w drugim kroku (przekierowanie), czy można go zmodyfikować,

Dodatkowo:

• znaku + nie można używać bezpośrednio w wartości parametru (jest traktowany jako spacja),
• 1=1 nie jest jedyną możliwością (można znaleźć inne wyrażenia, które są zawsze prawdziwe),

Oryginał tego wpisu dostępny jest pod adresem Bootcamp II(c|d): hinty

Autor: Paweł Goleń

Po dłuższej przerwie kolejne przykłady:

• http://bootcamp.threats.pl/lesson02c/
• http://bootcamp.threats.pl/lesson02d/

Zadanie jest proste – odczytać wiadomość o identyfikatorze 2161. W obu przypadkach ta wiadomość jest taka sama. Same przykłady są bardzo podobne do siebie, a cel można osiągnąć na kilka sposobów.

Powodzenia!

P.S. Inspiracją tego przykładu (jego części) jest jedno zdanie wypowiadane w tym filmiku. Które?

Oryginał tego wpisu dostępny jest pod adresem Bootcamp II(c|d)

Autor: Paweł Goleń

Pamiętacie rozważania odnośnie tego, czy pierwsza odpowiedź jest najlepsza? Miałem wówczas poważne wątpliwości, czy twierdzenie to zostało słusznie uznane za mit. Wątpliwości te bynajmniej się nie zmniejszyły, co więcej słuchałem sobie ostatnio interesującego podcastu (wiekowego dość), w którym pada zdanie będące tytułem tego wpisu.

Podcast jest do odsłuchania tutaj: Potęga podświadomości, czyli uwierz, że wiesz. Całość dość długa, ale moim zdaniem warta posłuchania. Dodatkowo można też posłuchać tych podcastów: Intuicja w pracy i w życiu osobistym oraz Czy intuicja jest sprzeczna z racjonalnością.

I może ta pierwsza odpowiedź jest właśnie intuicyjna?

Oryginał tego wpisu dostępny jest pod adresem Myślenie przeszkadza w myśleniu

Autor: Paweł Goleń