Ubudne gæster

Af Jesper Kristensen, 09-02-2011 18:39

Vi har desværre haft ubudne gæster her hos MozillaDanmark. Nogen har haft adgang til dele af vores hjemmeside, som de ikke skulle have haft adgang til.

Gerningsmændenes formål ser ud til at have været at bruge vores PageRank hos søgemaskinerne til at sprede spam-links. Vi tror umiddelbart ikke de er gået efter data om vores brugere eller på anden vis har forsøgt at skade de besøgende, men vi kan ikke være 100% sikre. Hvis du er registreret som bruger i vores forum og du bruger samme adgangskode hos os som andre steder, kan det derfor være en god ide at ændre din adgangskode.

Hvad er der sket?

Angriberne har på en eller anden måde fået adgang til at plante uønsket PHP-kode på vores server. Koden lå spredt rundt omkring i flere mapper i både nye og eksisterende filer. Efter et nærmere kig på koden ser det ud til at formålet har været to ting:
  • Fylde vores side med spam-links hver gang en søgemaskine kom forbi. Koden forsøger at skjule disse links fra normale brugere, så kun søgemaskiner kan se dem, men det har ikke altid virket, og almindelige brugere har derfor også en gang imellem kunnet se denne spam.
  • Sikre fremtidig adgang ved at placere komponenter fra kendte CMS-systemer, som gør angriberne i stand til at komme tilbage og ændre deres spam-links eller lægge nyt kode ind.

Hvor længe har de haft adgang?

De ældste filer vi har fjernet var dateret 28. januar, og vi fandt og fjernede de sidste filer 4. februar.

Hvordan har de fået adgang?

Vi ved det ikke, men der er tre teoretiske muligheder:
  1. De har opdaget adgangskoden til vores FTP-konto hos vores udbyder Surftown.
  2. De har fundet et sikkerhedshul i noget af den PHP-software vi kører (phpBB, WordPress, MediaWiki og diverse småting)
  3. De har fundet et sikkerhedshul i Surftowns systemer og har angrebet os via andre brugere.
Vi anser (3) for højest usandsynlig, og vi anser (2) som den mest sandsynlige.

Hvordan har vi fjernet koden?

Det meste af vores kode er standardsoftware (phpBB, WordPress og MediaWiki). Vi har derfor nemt kunne hente en ren udgave af softwaren fra producenternes hjemmesider, og har sammenlignet dem med hvad vi havde liggende (diff er et godt værktøj til dette formål). Vi har minutiøst gennemgået enhver forskel og verificeret om det er en vi selv har lavet eller om det var en del af angribernes kode.

Hvordan undgår vi at det sker igen?

FTP

Vi har ændret vores adgangskode til vores FTP-konto, og der er nu færre medlemmer, som kender koden. Samtidigt er det nu kun aktive medlemmer, der kender koden (Kim Ludvigsen , Søren Munk Skrøder og Jesper Kristensen).

PHP

Vi har også gennemgået vores PHP-software for sikkerhedsproblemer. Vi fandt ingen problemer i vores egen kode. Vores installerede udgaver af phpBB og WordPress var også opdaterede med sikkerhedsopdateringer. Vi fandt derimod ud af at vi brugte en gammel udgave af MediaWiki med kendte sikkerhedskuller. Den har vi nu opdateret til nyeste udgave. Vi gætter på at angriberne er kommet ind denne vej.

MediaWiki

Jeg var på et tidspunkt tilmeldt MediaWikis mailingliste for sikkerhedsopdateringer, men jeg må af en eller anden grund være røget af den, for jeg har ikke fået mail om sikkerhedsopdateringer i lang tid. Jeg er nu tilmeldt mailinglisten igen, så vi kan følge med sikkerhedsopdateringerne til MediaWiki. Her vil jeg gerne tillade mig at kritisere folkene bag MediaWiki for kun at stille en oldnordisk og uigennemskuelig mailingliste til rådighed. Folkene bag phpBB gør det fx meget bedre ved at stille et smart web feed til rådighed, og med web feeds er der ingen tvivl om hvorvidt beskederne når frem eller ej.

Hvordan styrker vi sikkerheden?

Jeg går kraftigt ind for sikkerhed i flere lag. Som jeg tidligere har skrevet her på bloggen, har vi fx indført Content Security Policy her på siden (CSP har dog intet med dette angreb at gøre, da den er designet til at beskytte mod helt andre trusler).

Databasen

Som ekstra beskyttelse af databasen bruger hver PHP-applikation hver deres database med hver deres adgangskode. phpBB kan fx ikke se eller rette i databasen tilhørende WordPress og omvendt. Samtidigt kører databasebrugeren med minimale rettigheder. Sådan har vores opsætning været længe før dette angreb. I den forbindelse vil jeg gerne give ros til Surftown for at gøre det muligt for os som kunder at oprette flere forskellige databaser med forskellige brugere og for at give os mulighed for at styre brugerrettighederne i mange detaljer via deres kontrolpanel.

Webserveren/PHP

På PHP-området er det straks sværere at indføre ekstra beskyttelseslag. Surftown kører med PHP safe_mode, hvilket gør det svært at lave et multibruger-setup med begrænsede rettigheder til hver bruger. Men de kører kun med safe_mode_gid, så det kunne teoretisk være muligt. Men Surftown giver ikke mulighed for at oprette flere brugere og ændre filejerskaberne (chown).

Som om det ikke var nok at vi kun har én bruger, som er ejer af alle vores filer, kører webserveren også som denne bruger, og vi har derved så vidt jeg kan se ingen mulighed for at forhindre webserveren i at have læse- og skriveadgang til alle vores filer. Hvis vi havde haft det, kunne vi begrænse angribernes adgang til mapper med caches og billeduploads, og vi kunne have forhindret al PHP-kørsel i disse mapper, således at angriberne ikke ville have haft mulighed for at udnytte sikkerhedshullet i MediaWiki.

En anden begrænsning er at Surftown kun kører PHP 5.2. I modsætning til version 5.3, er det i denne version ikke muligt at lave yderligere restriktioner på open_basedir i fx .htaccess-filer, hvilket kunne have forhindret angriberne i at sprede sig fra wikien til forummet, bloggen og vores statiske sider.  Jeg håber Surftown opgraderer meget snart.

Netværkskryptering/FTP

Vi har adgang til vores filer via FTP. FTP-protokollen er som bekendt usikker, og man bør bruge fx SFTP eller SCP i stedet, men Surftown tilbyder ingen af disse muligheder, så det kan vi ikke.

Netværkskryptering/HTTP

Jeg har også for noget tid siden forsøgt at få SSL-kryptering på de dele af vores site, som har login (eller i det mindste til admin-områderne). Men SSL kræver enten en selvstændig IP eller SNI. Surftown tilbyder ikke selvstændig IP til det abonnement vi har, og en marginalt øget sikkerhed er ikke nok til at jeg vil betale det dobbelte for vores hosting på et dyrere abonnement. Jeg har desuden spurgt Surftown om de i stedet understøtter SNI, men de svarede at det gør de ikke, og de har ingen planer om at gøre det.

Til sidst

Det var så min gennemgang af sikkerheden her hos os. Jeg er overbevist om at vi har fået bugt med indbrudstyvene, og at mozilladanmark.dk nu er mere sikker end nogensinde. Men ser du noget mystisk er du som altid mere end velkommen til at give os besked. Jeg håber at vores erfaringer kan hjælpe andre med at blive lidt klogere på sikkerhed på webservere.

Opdateret: Indlægget er rettet efter Surftown Support har bekræftet at de hverken tilbyder SFTP/SCP eller multibrugersikkerhed for webserver og PHP.