Wampiryczny blog

Wolę nie myśleć od ilu już lat korzystam z bankomatów... Kiedyś korzystanie z bankomatów było szybsze, a teraz? Teraz każda operacja jest doskonałą sposobnością do umieszczenia krótkiego filmiku reklamowego. Oczywiście filmik trwa dłużej, niż operacja, ale kto by się tym przejmował.

O ile SQLi w formatce logowania nie jest zbyt powszechny, przynajmniej nie był w tej próbce aplikacji, które miałem okazję testować, to XSS w loginie użytkownika zdarzał się już częściej (patrz: Lekcja 21: Przykład - phishing na formatce logowania z wykorzystaniem XSS).

Okazuje się, że ten przykład również jest "zaimplementowany" w Altoro Mutual. I tak, ktoś musiał się odrobinę postarać by taki błąd tam umieścić, ponownie odsyłam do mojego dawnego wpisu Niekonsekwencje w ASP.NET.

Na początek założenie - ten wpis nie będzie powstawał dłużej niż 30 minut. O czym będzie - o oczywistych oczywistościach, które rzucają się w oczy w Altoro Mutual. Zacznijmy od części dla użytkownika nieuwierzytelnionego.

Już od kilku lat nie zajmuję się bezpośrednio testowaniem, ale od czasu do czasu nachodzi mnie ochota, by się pobawić i sprawdzić jak bardzo "zardzewiałem". Wiele czasu na to nie mam, ale tak jakoś w takiej wolniejszej chwili w katalogu OWASP Vulnerable Web Applications Directory Project znalazłem to: Altoro Mutual.

Tak, ta strona powstała po to, by pokazać jak bardzo pewne skanery są efektywne w związku z czym jest nafaszerowana podatnościami w sposób nieco nierealistyczny, ale... No właśnie, tych podatności jest może za dużo, za łatwo je znaleźć (wpisywanie szczegółowych informacji o błędach mogli sobie darować), ale same typy podatności są prawdziwe. To nie jest jakiś CTF bardzo wyrafinowany technicznie, ale prezentujący jakiś przypadek praktycznie niewystępujący w naturze. Takie podatności naprawdę znajdowałem w trakcie pracy i wiem, że nadal są znajdowane.

Na stronie OWASP podane są dane do logowania jednego z użytkowników, ale (mały spoiler) nie są potrzebne. Być może (znów - zależy od czasu) napiszę kilka słów / przykładów jak się do testowania zabrać.

I na koniec "wyzwanie" - dojść do tego w jaki sposób w tej aplikacji można wykonywać przelewy bez uwierzytelnienia. Jeśli ktoś chce podnieść poprzeczkę - dojść do tego jak to zrobić mając do aplikacji wyłączenie dostęp anonimowy (hint: SWRlbnR5ZmlrYXRvcnkgdcW8eXRrb3duaWvDs3cgc8SFIGR6aWV3acSZY2lvY3lmcm93ZS4gSGludCAyOiBUbUVnY0hKNmVXdkZnbUZrT2lBeE1EQXhNVFl3TVRNPQ==).

Słucham sobie podcastu (Daily Stormcasts) i nagle słyszę o tym: Over 18,000 Redis Instances Targeted by Fake Ransomware.

Ekhm, ekhm:

In a nutshell, this attack is performed by:

• Sending a CONFIG command telling Redis to store key/values on disk in the “/root/.ssh/authorized_keys” file
• Setting a key/value pair with the value being a public SSH key
• The attacker can now log into the Redis instance via SSH as the root user

Taaaak.... Tak to się kiedyś właziło przez Oracle - manipulacja TNS Listener tak, by nadpisać plik authorized_keys logami, które zawierały klucz publiczny atakującego. Świat się jednak nie zmienia.