Kryptografia jest ważna, ale to nie jest magic dust , którym wystarczy posypać system, by stał się on automatycznie bezpieczny. Z kryptografii należy korzystać, ale trzeba znać jej ograniczenia. Niestety, w trakcie testów często spotykam się z sytuacją, w której kryptografia jest użyta w sposób nieprawidłowy. Dziś trochę na ten temat.
Czasami dostaję pytanie, co robię, gdy znajdę jakąś podatność. Oczywiście mowa o sytuacji, kiedy zdarzy mi się coś znaleźć poza działaniami związanymi z realizacją zleceń. W moim przypadku odpowiedź jest prosta – nic. Po prostu “po pracy” nie szukam podatności, a jak coś mi się rzuca w oczy, to po prostu zamykam jedno oko i udaję, że drugim tego nie widzę. Dlaczego?
Odpowiedź na to pytanie również jest dość prosta i można ją przedstawić prostym akronimem CY(O)A. Jeśli organizacja nie ma jasno określonego programu bug bounty , wolę nie sprawdzać organoleptycznie w jaki sposób potraktuje informację o podatności. Wolę nie być później w sytuacji, w której będę musiał udowodnić, że nie jestem wielbłądem.
Jeśli zastanawiasz się o co chodzi w tytule tego wpisu, to spieszę wyjaśnić, że o nic. Po prostu nie miałem pomysłu jak go zatytułować, więc wygenerowałem sobie coś takiego :) A to dlatego, że wpis ten nie ma żadnego konkretnego tematu. No dobrze, może i ten tytuł ma pewien ukryty sens, ale to mocno poboczna sprawa.
Przynajmniej dwie osoby rozwiązały moje wyzwanie, to znaczy rozwiązały wszystkie pierwotnie opublikowane zadania, nie mam na razie żadnych informacji odnośnie zadania siódmego. Oczywiście zadania rozwiązać mogło więcej osób, mogły się po prostu nie pochwalić :) Feedback jest znikomy, choć raczej pozytywny:
Thanks for the nice challenges, really enjoyed it, especially number 5 was really good. Just solved the last one (...)
Czekam na więcej :)
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ń
Rzucił mi się dziś w oczy dość stary felieton, w którym autor “rozprawia się” z narzekaniem nauczycieli/wykładowców na młode pokolenia, że jego przedstawiciele “nic się nie uczą na pamięć, wszystkiego szukają”. Autor wykazywał różnice w dostępności wiedzy kiedyś i teraz, powoływał się również na książkę The Wisdom of Crowds. A ja się z nim nie do końca zgadzam.
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:
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:
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ń
Dość typowym sposobem realizacji funkcji resetu zapomnianego hasła jest generowanie losowego tokenu, który następnie wysyłany jest na zapisany w systemie adres e-mail. Korzystając z tego tokenu, można ustawić nowe hasło. O tym, że sposób ten nie jest najlepszy można przeczytać tutaj: OWASP Forgot Password Cheat Sheet i posłuchać tu: OWASP Podcast #83. Ale ja dzisiaj o trochę czym innym.
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ń