W niedawnym ataku na stronę WWW atakujący wykorzystał mało znaną właściwość serwerów MS SQL, pozwalającą na uzyskanie 22-krotnego wzmocnienia ataku. Podatnych serwerów może być około 700 tysięcy, zatem warto przyjrzeć się problemowi.
Podstawowym narzędziem ataków DDoS jest wykorzystanie tzw. wzmocnienia (amplification). Polega ono na znalezieniu usług i serwerów, które po otrzymaniu krótkiego zapytania ze sfałszowanego adresu nadawcy prześlą na fałszywy adres dłuższą odpowiedź. Dzięki temu atakujący może np. wykorzystując łącze o przepustowości 100Mb/s wygenerować atak o mocy 10 czy 100 razy większej, ukrywając jednocześnie swoją tożsamość.
Ciekawe pakiety
W grudniu witryna WWW miasta Columbia padła ofiarą ataku DDoS. Atakujący wykorzystywał różne popularne techniki ataku takie jak wzmocnienie SSDP czy NTP. Części pakietów nie udało się jednak przypisać do żadnego znanego rodzaju ataku i poddano głębszej analizie. Wyglądały one tak:
Fragment listy pakietów
a tak wyglądała ich zawartość:
Zawartość pakietów
Mamy więc pakiety UDP przychodzące na port 1434 i zawierające informacje o serwerach MS SQL. Jest to wynik działania usługi SQL Server Resolution Service, która w oparciu o SQL Server Resolution Protocol udziela klientowi informacji o konfiguracji serwera. Usługa ta jest aktywna na wszystkich serwerach MS SQL od wersji SQL Server 2000. Shodan wskazuje, że w sieci dostępne jest ponad 700 000 potencjalnie podatnych serwerów.
Osiągane w ten sposób wzmocnienie ataku zależy od konfiguracji wykorzystywanego serwera, ale średnio można przyjąć, że wyniesie ok 22x. Przykładowy skrypt w Pythonie testujący podatność serwera:
import socket
HOST_IP = "192.168.1.1"
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.connect((HOST_IP, 1434))
qry = bytes.fromhex('02')
sock.send(qry)
ans = sock.recv(5120)
print(ans)
Wyłączenie usługi na serwerze może nie być najlepszym rozwiązaniem, ponieważ może z niej korzystać cześć narzędzi bazodanowych. Znacznie lepiej jest trzy razy rozważyć sens umieszczania serwera MS SQL na publicznym adresie IP przy braku ograniczeń na ruch przychodzący i wychodzący.
Autorzy ataków DDoS szybko przyswajają rynkowe nowinki, zatem możemy się spodziewać, że wkrótce do ataków NTP czy SSDP dołącza także ataki MC-SQLR. Administratorzy serwerów MS SQL – filtrujcie ruch lub chowajcie serwery w sieci wewnętrznej zanim dowiecie się, że były wykorzystane do ataku.
Komentarze
tak napewno. Baza na publicznym ip bez zabezpieczen. Adam mysl troche
Przeczytaj jeszcze raz treść zdania, które sprawia Ci problem.
To, że się da postawić serwer MS SQL na publicznym adresie, bez zabezpieczeń oznacza tylko jedno – że takich serwerów znajdziemy sporo…
No właśnie, Adam.
„wykorzystując łącze o przepustowości 100MB”
Wybaczcie czepialstwo, ale przepustowości nie mierzy się w MB lecz w bitach na sekundę.
Czemu? Przecież można podać długość przy rodzenia w m zamiast w cm. Przeliczyć nie potrafisz ;p?
Chcesz powiedzieć, że dla Ciebie m (metry) to cm/s (centymetry na sekundę)?
Poza tym nie wiem czego długość chcesz podawać przy rodzeniu. Chyba, że „przyrodzenia”. Obvious troll is obvious. :/
Jednostki czasu brakuje….
A jeśli chodzi o uwalenie pakietu shared-hostingu? :)
100MB czyli jakieś 800 Mbps :P
Nie prawda. 100 MB = 800 Mb, dopiero 100 MB/s = 800 Mbps (po angielsku). Ale po takim czasie, to pewnie w artykule nikt już nie będzie poprawiał, tym bardziej, że w slangu coraz częściej stosowany jest taki skrót myślowy, jaki zaprezentowałeś. :-)
Poprawione.
A jednak. Dziękuję bardzo. :-)
Ja też się zastanawiam jaki jest sens wystawiania portu 1434 na świat. Przecież są VPN i RDP, więc w czym problem administrować czy programować zdalnie?
Ta liczba 700k tez przesadzona, kurcze nigdy nie spotkałem się z serwerem mssql wystawionym na zewnątrz.
To brzmi całkiem realnie. Sam „padłem” ofiarą MS SQL Slammera w roku 200x przez po prostu omyłkowe ACLe na publiczny DMZowy adres serwera. A przy wielu projektach, które skanują dostępne usługi w sieci internet wykorzystanie takich „ofiar”, to tylko kwestia czasu…