24 June 2008

Ataki SQL Injection na naszego SQLa?

Dostałem informację z Redmond, że podobno na całym świecie w ostatnim okresie nasiliły się skuteczne ataki na bazy danych.

Ataki te dotyczyły również i naszego SQL Servera, aczkolwiek to sformułowanie celowo ma pewien błąd merytoryczny.

Bo problemem nigdy do tej pory nie była żadna słabość naszego oprogramowania a jedynie niezbyt dobrze napisany kod aplikacji działającej w oparciu o SQL (ale równie dobrze mogła to być dowolna baza danych). Problem ten jest też znany pod pojęciem SQL Injection.

Zacytuję wypowiedź ekspertów z naszego teamu zajmującego się takimi kwestiami:

These attacks do not leverage any SQL Server vulnerabilities, nor any un-patched vulnerabilities in any Microsoft product – the attack vector is vulnerable customer and third party applications. 

Powstała też strona opisująca jak radzić sobie w firmie z tego typu problemami i to zarówno z punktu widzenia programisty jak i administratora.

Zachęcam do przejrzenia posta na blogu Security Vulnerability Research & Defense, gdzie opisany jest cały problem oraz rekomendacje zespołu SVRD.

Ja na koniec dodam jako ciekawostkę, że Microsoft SQL Server nadal pozostaje środowiskiem bazodanowym bez żadnej luki krytycznej przez ostatnie 4 lata!

Filed under: ,
 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# brejk said:

Mariusz, z tym brakiem krytycznej poprawki w temacie bezpieczeństwa to powiem Ci, że można być zadowolonym, ale i zaniepokojonym :-) Bo to może znaczyć, że szykuje się większe "BUM" ;-) Prawa Murphy'ego nie oszukasz :D

25 June 08 at 8:14 AM
# masakra said:

Normalnie jak cytat z filmu chyba "Chlopaki nie placza"...

"Nauczyciela oszukasz, babcie oszukac, tatusia oszukasz... ale synku zycia nie oszukasz" - albo jakos tak :)

Na szczescie na razie nic o zadnym BUM nie slychac i mam nadzieje ze tak zostanie :)

25 June 08 at 9:08 AM
# ziembor said:

Wystarczył SP2 do 2005 by DDoSa zapewnić.

Ile udało się poprawek doczekać by SP2 chodził stabilnie po swoim RTM?  5?  

polecam np. http://support.microsoft.com/kb/934458

:)

30 June 08 at 10:37 PM
# ziembor said:

aha. http://nvd.nist.gov/nvd.cfm?cvename=CVE-2004-1560 zostało opublikowane mniej niż 4 lata temu :)

to w sumie też:

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-4814

(tak, wiem, że odnosi się do legacy kodu, z SQL 2000, ale dostępnego razem z SQL 2005 SP2).

Dobra, poflajmowałem, idę spać. Miłego dnia :)

30 June 08 at 10:44 PM
# szelor said:

No i wykrakaliście:

http://www.microsoft.com/technet/security/bulletin/ms08-040.mspx?pubDate=2008-07-08

Entropią górą

09 July 08 at 6:10 AM
# masakra said:

Ale z tego co widze, to te z biuletynu 08-040 to maja status "Important" a nie "Critical" :)

09 July 08 at 9:23 AM
# Rybek said:

hmmm jesli takie coś "http://www.microsoft.com/downloads/details.aspx?FamilyID=a60bb7e7-ef4e-4cbd-b63a-0ad7bd1402b3&DisplayLang=en" to nie critical to sql server nigdy nie bedzie mial croticala chyba ze sie polozy poprostu :P

17 July 08 at 8:39 AM
# ziembor said:

nie do końca przeczytałeś lub znasz reguły klasyfikacji.

Critical to jest coś co jest pdodatne od razu i zawsze + anonimowo. wszyscy klasyfikatorzy błedów (np. Secunia) http://secunia.com/advisories/30970 kwalifikują go jaki ważny, acz nie krytyczny. Choć dla środowisk typu niezaufani i duże masowe instalacje korzystające z baz danych bład jest poważny i lepiej go załatać (zwłaszcza jeśli jak.... .... ... postawiło sie bazę na Local System). Ale wcale nie jest łatwy do użycia (choć jak już pierwszy bootnet go opanuje to... potoczy się). Ale wtedy klasyfikacja błedy gwałtownie podskoczy.

17 July 08 at 7:08 PM

Leave a Comment

Comment Policy: No HTML allowed. URIs and line breaks are converted automatically. Your e–mail address will not show up on any public page.

(required) 
(optional)
(required) 

  
Enter Code Here: Required
Page view tracker