Gamle Wordpress-blogs under angreb

Gamle Wordpress-systemer er blevet angrebet i løbet af weekenden. Alle systemer, som er ældre end den seneste version, er sårbare overfor angreb.

Gamle udgaver af blog-publiceringssystemet Wordpress har været udsat for angreb i den forgangne weekend.

Samtlige udgaver af Wordpress, som er ældre end den nuværende version 2.8.4, er angiveligt sårbare for angreb. Det skriver avisen The Guardian.

Ifølge Wordpress-udvikleren Matt Mullenweg er der tale om en orm.

»Lige nu er der en orm, som vandrer rundt på gamle, upatchede udgaver af Wordpress. Denne orm, ligesom mange før den, er klog: Den registrerer en bruger, benytter et sikkerhedshul (rettet tidligere på året) til at få kode afviklet via permalink-strukturen, gør sig selv til administrator og benytter så et Javascript til at skjule sig, når man kigger på bruger-siden, forsøger så at rydde op efter sig selv, og bliver så stille, så du aldrig bemærker, at den indsætter skjult spam og malware i dine gamle indlæg.«

Wordpress har en hullet forhistorie. I de sidste par år er der fundet mange sikkerhedsrelaterede fejl systemet, og det danske firma Secunia vurderede i foråret, at der på det tidspunkt stadig var syv huller i softwaren, som firmaet dog vurderede til at være mindre kritiske.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (11)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Anonym

Overordnet giver artiklen ikke rigtig mening(IMO).

Det er jo ingen kunst at sikre mod skadeligt input, ej heller at sikre mod skadeligt output.

I forhold til sårbarheder kunne 'man' bare lave et code reviwew, så burde den ged være barberet.

Står vi overfor en situation, hvor man eksponerer kode - fordi det virker - eller er der manglende substans i kvalitetssikringen (if any)?

Det kan godt være jeg er dum, men jeg forstår ikke sentensen

Lige nu er der en orm, som vandrer rundt på gamle, upatchede udgaver af Wordpress

Man får indtrykket af, at der er tale om en 'orm', der vandrer rundt, men det har jeg svært ved at forestille mig.

Jo, 'inficering' osv, men ikke en orm, der aktivt 'vandrer rundt'.

  • 0
  • 0
#2 Thomas Stig Jacobsen

Jeg ser ikke denne nyhed som en reel nyhed eller overraskelse.

Det helt normalt at efter en offentliggørelse af et så stort hul i så en kendt og benyttet platform/applikation vil hullet blive brugt af diverse script kiddies osv. Tiden der imellem bruges til yderligere udspredelse eller til fremstilling af værktøjer som automatiserer en udnyttelse af hullet.

  • 0
  • 0
#3 Deleted User

Man får indtrykket af, at der er tale om en 'orm', der vandrer rundt, men det har jeg svært ved at forestille mig.

Jo, 'inficering' osv, men ikke en orm, der aktivt 'vandrer rundt'.

Jeg tror at den orm inficerer en wordpress installation og bagefter så giver den sig til at scanne efter andre wordpress installationer som den så også inficerer. Den nye wordpress installation giver sig så igen til at scanne efter andre wordpress installationer osv.

  • 0
  • 0
#4 Hans-Michael Varbæk

En "web-orm" inficerer usikre web-applikationer som i dette tilfælde, upatchede versioner af Wordpress.

Denne skal kunne replikere sig selv ved at kunne angribe andre steder, dette gøres ved scanning. Dette kunne eventuelt være ved specielle google-søgninger eller bare ip-addresse scanninger efter web-servere som har wordpress installeret, dog er google-søgninger vha. "Google Dorks" nok det letteste i dette tilfælde.

At identificere en upatchet version af Wordpress kan gøres på 2 måder og er relativt simpel, enten søger ormen efter et bestemt nøgleord som er ændret i den patchede version, ellers også prøver den bare på at inficere web-stedet.

  • 0
  • 0
#6 Anonym

Denne skal kunne replikere sig selv ved at kunne angribe andre steder, dette gøres ved scanning

Det er jeg med på, men jeg kunne forestille mig, at man bruger bot's til denne manøvre.

Så i min terminologi synes jeg ikke der er tale om en 'orm', men det er nok ordkløveri.

Dem der har angrebsforsøg i logfilerne burde kunne identificere hvorvidt det er en server eller en PC, der ligger bag IP adressen.

Hvis det er en inficeret server, der replikerer, bør der som minimum være en lytter på port 80.

[b]Ad kvalitets sikring.[/b] Jeg er ikke PHP-haj, men jeg kan godt læse det. Jeg søgte lidt, og kiggede lidt, og fandt frem til funktionen, der forsøges udnyttet, angiveligt via SQL injection.

Desværre kunne jeg ikke finde eksempler på den referrer, der benyttes som indhold, så jeg kan ikke udtale mig om funktionaliteten [b]men[/b]:

Jeg bemærkede, at funktionen query i wp-includes/wp-db.php: http://wordpress.taragana.net/wp-includes/wp-db.php.source.html#l131 [b]ikke[/b] benytter parameterized queries/prepared statements.

'Vi andre' har vidst i mindst 15 år, at det er den eneste rigtige måde at kode mod databaser, så det er for mig uforståeligt, at man ikke forlængst har rettet så åbenlyse 'fusere'.

Som nævnt i mit oprindelige indlæg, så vil jeg anbefale at man laver code review, og får lavet alle databasekald om til parameterized queries.

Så er man sikret mod SQL injection up front, og behøver ikke at vente på opdagelsen af det næste hul.

Jeg kan forestille mig, det er en kæmpe opgave at renovere Wordpress, men det er den eneste fremtidssikrede metode - IMO.

  • 0
  • 0
#7 Anonym

Jeg var alligevel lidt nysgerrig efter at finde eksempler på den kode, der skulle eksekveres.

Det gik op for mig, at fidusen med at indsætte disse eval(base64_decode($_SERVER[HTTP_REFERER]) 'ting' reelt betyde, at man kan afvikle arbitrær PHP kode, blot ved at levere den encodede kode i referrer.

Det betyder, at for dem hvor angrebet er lykkedes, kan [b]HELE SERVEREN[/b] være kompromitteret.

Med andre ord er det muligvis ikke nok at rense databasen, da det sagtens kan være lagt 'sjove' PHP filer på serveren.

Det kan være små effektive, som namogofer, eller en større multifunktionel 'administrator kit'.

Jeg vil anbefale at man undersøger [b]hele serveren[/b] hvis man har været ramt.

Folk har det desværre med at fortie angreb, så vi får nok aldrig at vide hvem, og i hvilket omfang, der er/har været ramt.

Jeg synes det ville være rart at vide, for der kan lige så godt være injected malicious javascripts, der i sidste ende fører til malware/trojanere etc. på brugernes PC'ere.

  • 0
  • 0
#9 Deleted User

Ah. Angrebet vil stadig være begrænset til de privilegier som PHP har. Oftest er dette www-data brugeren, i hvert fald på apache/Linux setups, og denne har sjældent skriverettigheder til noget af betydning.

Det værste der kan ske er at ormen har inficeret andre websites på samme hosts - de fleste shared hosting steder kører stadig med safemode, så den risiko er vi dog forholdsvis ude af. Og folk der hoster selv, er også selv ansvarlige for deres sikkerhed.

  • 0
  • 0
#10 Ole Juul

Som jeg forstår det skal man så først have et password.

Fra WordPress høre vi: "...a specially crafted URL could be requested that would allow an attacker to bypass a security check to verify a user requested password reset. As a result, the first account without a key in the database (usually the admin account) would have its password reset and a new password would be emailed to the account owner."

  • 0
  • 0
#11 Anonym

Det er fint nok, at man ikke forstår [b]rækkevidden[/b] af denne exploit.

Som man siger ovre i vendsyssel: "Kun en tåbe frygter ikke havet"

Jeg brugte lidt tid på at Google, og observerede, at nogle har fået modificeret deres index.php fil som følge af denne exploit.

Links har jeg ikke noget af, da enhver der interesserer sig for server sikkerhed burde kunne finde det samme.

På samme måde kan der sagtens være placeret/injected adskillige filer.

Jeg vil ikke påstå at det er sket, men [b]muligheden[b] er der.

  • 0
  • 0
Log ind eller Opret konto for at kommentere