image

Grootschalige SQL-injectie treft 250.000 sites

woensdag 14 mei 2008, 12:24 door Redactie, 12 reacties

Na de recente SQL-injectie aanval waarbij meer dan 500.000 websites werden gehackt, is er een nieuwe ronde gaande waar al tenminste 250.000 sites van een kwaadaardig Javascript zijn voorzien. De scripts verwijzen voornamelijk naar Chinese domeinen die via verschillende exploits de computers van bezoekers proberen te infecteren. Het gaat onder andere om de domeinen yl18.net, www.bluell.cn, www.kisswow.com.cn, www.ririwow.cn en winzipices.cn. Alleen het script http://www.kisswow.com.cn/m.js bevindt zich al op 149.000 sites.

Volgens het Finse F-Secure zijn er nu meerdere groepen bezig met het massaal hacken van websites op deze manier en gebruiken ze verschillende geautomatiseerde tools om de code te injecteren. De aanval gebruikt geen beveiligingslek in Microsoft's IIS, maar slordig programmeerwerk, zoals de softwaregigant al eerder liet weten.
afbeelding

Reacties (12)
14-05-2008, 14:20 door Anoniem
Is al duidelijk wat een gebruiker kan ondernemen om
problemen te voorkomen?
14-05-2008, 15:25 door lievenme
Door Anoniem
Is al duidelijk wat een gebruiker kan ondernemen om
problemen te voorkomen?

ik vermoed dat die virtuele browser met sandboxie een
oplossing biedt!!

ten minste als die webstek intussen nog niet geïnfecteerd is...
14-05-2008, 16:18 door Anoniem
expert.be en twice it zitten er ook bij lol....
14-05-2008, 21:26 door Anoniem
Door Anoniem
Is al duidelijk wat een gebruiker kan ondernemen om
problemen te voorkomen?
Gebruikers: NoScript plugin gebruiken.
Ontwikkelaars: inputvalidatie.
14-05-2008, 22:46 door Bitwiper
Door Anoniem
Is al duidelijk wat een gebruiker kan ondernemen om problemen te voorkomen?
Om te beginnen zorgen dat je besturingssysteem, browser en alle plugins gepatched zijn. Vooral exploits voor de RealPlayer plugin zijn de laatste tijd populair, maar exploits voor niet-up-to-date Flash, QuickTime en Acrobat reader plugins komen vermoedelijk ook voor.

Verder richten veel exploits zich op MSIE (gebruiken bijv. VBscript en/of ActiveX plugins welke Firefox standaard geheel niet ondersteunt).

Als je Firefox uitbreidt met [url=http://noscript.net/]NoScript[/url] ben je goed gewapend tegen het huidige type exploits, zelfs als je Firefox (middels NoScript) toestemming geeft om scripts van een gehackte site uit te voeren. De reden is dat bij de huidige golf van exploits steeds javascript vanaf een andere server (met daarop meestal meerdere exploits) wordt opgehaald; zolang je javascripts vanaf die server geen toestemming geeft ben je safe. Bij toekomstige eploits valt echter niet uit te sluiten dat malware-houdende scripts in gekraakte servers worden ge-inject.

Trouwens, als ik in de Google cache van [color=blue]www_procase_nl[/color] kijk (retrieved on 9 May 2008 23:58:27 GMT) zie ik nog javascript vanaf [color=blue]www_kisswow_com_cn[/color] komen, maar in de actuele page is dat momenteel [color=blue]www_wow112_cn[/color]; die URL's zijn kennelijk net vervangen, want Googlen naar www_wow112_cn (underscores door punten vervangen) geeft nog nauwelijks hits.

Voor de fanatieke block-listers onder ons: die laatste site wordt al wel op [url=http://www.shadowserver.org/wiki/pmwiki.php?n=Calendar.20080514]ShadowServer[/url] genoemd. Op die lijst heb ik nog enkele aanvullingen (met relatief lage Google hitrates): [color=blue]c11_8866_org[/color], [color=blue]w11_6600_org[/color] en [color=blue]d39_6600_org[/color].
15-05-2008, 09:34 door Anoniem
... bevindt zich al op 149.000 sites.

Hier wordt waarschijnlijk bedoeld dat er 149.000 infecties
hebben plaats gevonden. 1 hit op Google komt niet persee
overeen met 1 site.
15-05-2008, 09:42 door Anoniem
Ontwikkelaars: inputvalidatie.
Dat is slechts een deel van de oplossing. Het kan namelijk
heel valide zijn dat een string bijvoorbeeld een enkele
quote bevat. De oplossing is dan NIET om deze bij het
valideren van de invoer gelijk al te vervangen door twee
enkele quotes (zoals helaas door vele programmeurs wordt
gedaan). Dat moet je pas doen bij het samenstellen van je
SQL statement. Of nog beter, gebruikt prepared SQL
statements / parameter binding en/of stored procedures.

Daarnaast is het alleen het vervangen van enkele of dubbele
quotes lang niet voldoende. Er zijn nog veel meer tekens
waaraan SQL Server speciale betekenis geeft. Ook die moeten
worden ge'escaped. En nogmaals, met prepared SQL statements
/ parameter binding en/of stored procedures speelt dat
probleem helemaal niet want dan lost de database laag het
voor je op.
15-05-2008, 11:38 door Anoniem
Door Anoniem
Ontwikkelaars: inputvalidatie.
Dat is slechts een deel van de oplossing.
(...) want dan lost de database laag het voor je
op.
Bravo. Dat heet ook gewoon, heel ordinair
wellicht, inputvalidatie.
15-05-2008, 15:41 door Anoniem
Door Anoniem
... bevindt zich al op 149.000 sites.

Hier wordt waarschijnlijk bedoeld dat er 149.000 infecties
hebben plaats gevonden. 1 hit op Google komt niet persee
overeen met 1 site.
Google is sowieso erg slordig met die schatting. Ze hebben
een of ander efficiënt algoritme om aan dat getal te komen
zodat ze processortijd besparen, met als excuus dat kleine
afwijkingen wel te tolereren zijn. Ik heb echter met mijn
eigen ogen meerdere gevallen geobserveerd waarbij ik
uiteindelijk maar 5% van het totaal aantal resultaten had
gezien toen de laatste pagina was bereikt.

Het kunnen dus net zo goed "slechts" 7000 infecties zijn.
Evengoed nog indrukwekkend, maar het gebruik van het aantal
hits dat Google geeft is absoluut geen betrouwbare maatstaf.
15-05-2008, 18:47 door SirDice
Daarnaast is het alleen het vervangen van enkele of dubbele quotes lang niet voldoende. Er zijn nog veel meer tekens waaraan SQL Server speciale betekenis geeft. Ook die moeten worden ge'escaped. En nogmaals, met prepared SQL statements / parameter binding en/of stored procedures speelt dat probleem helemaal niet want dan lost de database laag het voor je op.
Het grootste probleem met input validatie is dat het heel vaak niet gebeurd. Het tweede probleem is wat je hier eigenlijk schrijft. Men filtert op zaken die men NIET wil (quotes bijv.) waardoor er regelmatig dingen vergeten worden (denk ook aan Unicode en/of andere charactersets waarbij hetzelfde karakter verschillende voorstellingen hebben). Correcter is om te filteren op wat je WEL accepteert en de rest te verwijderen.
16-05-2008, 09:30 door [Account Verwijderd]
[Verwijderd]
16-05-2008, 13:06 door Anoniem
Door SirDice
Correcter is om te filteren op wat je WEL accepteert en de
rest te verwijderen.
Overzichtelijker en logischer
bovendien. Mocht de invoer toch niet voldoen, dan heb je
opvolgend de stap van de foutafhandeling.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.