Bezpieczeństwo web, SQL Injection – Eskalacja ataku

Czas wrócić do cyklu o bezpieczeństwie web, a konkretnie o SQL Injection. W poprzednich postach sporo pisałem o sposobach wykrycia luk, nawet w przypadku, gdy aplikacja nie wyświetla bezpośrednio danych na stronie.  Dzisiaj pokażę, że SQL Injection to nie tylko wykradnięcie danych, ale może umożliwić nawet całkowite przejęcie serwera.

Przedstawione ataki można wykonać na różnych typach baz, ale ze względu na to, że głównie zajmuje się MS Sql Server oraz MySql, ograniczę się do nich.

1. Wykonanie dowolnej komendy

W SqlServer do dyspozycji mamy xp_cmdshell.  Procedura umożliwia wykonanie dowolnej komendy systemowej, na przykład:

EXEC xp_cmdshell 'dir *.exe';
GO

Oczywiście, jeśli użytkownik wstrzyknie taką komendę i ConnectionString zawiera użytkownika, który ma uprawnienia do jej wykonania, atak zakończy się całkowitym przejęciem kontroli danego serwera. Po prostu, dowolne polecenie może zostać wykonane, więc nie różni się to niczym od fizycznego zalogowania się do takiego komputera.

2. Stworzenie nowego użytkownika

Wstrzykiwanie kodu za każdym razem jest dosyć niewygodne. Dlaczego zatem nie stworzyć po prostu sobie konta? Analogicznie, korzystając z technik pokazanych w poprzednich postach można wstrzyknąć CREATE LOGIN.

3.  Dostęp do infrastruktury

Zwykle systemy to nie pojedynczy serwer a cała ich sieć. Ponadto, sieć chroniona jest zwykle przez firewall, zatem z zewnątrz mamy dostęp wyłącznie do jednego serwera za pomocą HTTP\HTTPS. Innymi słowy większość portów i adresów IP jest po prostu zablokowana. Jeśli uzyskamy dostęp do serwera baz danych, np. za pomocą punktu pierwszego, znajdziemy się w zaufanej sieci. Potencjalnie serwer baz danych nie jest blokowany przez firewall ponieważ znajduję się w zaufanej sieci.

Naturalnie, za pomocą “xp_cmdshell” będziemy w stanie przeprowadzić kolejne ataki wymierzone w serwery znajdujące się w chronionej sieci. Zwykle są one dużo łatwiejsze do przeprowadzenia… Dlaczego? Programiści często myślą, że skoro aplikacja czy usługa jest wykorzystywana tylko wewnętrznie i nie ma do niej dostępu z publicznego Internetu, wtedy nie trzeba martwić się autoryzacją czy bezpieczeństwem. W świecie mikro-usług jest to dość wyraźnie widoczne. Często większość mikro-serwisów wykonywana jest wyłącznie wewnętrznie. Powyższe rozważania pokazują jednak, że wystarczy, że jakiś element w publicznych usługach zostanie złamany i atakujący zyska publiczny dostęp do usług, które wcześniej uważane były za prywatne. Bezpieczeństwo powinno być rozważane na każdym poziomie – od kodu aplikacji po infrastrukturę.

Leave a Reply

Your email address will not be published.