Php.net: hack trof twee servers

De beheerders van Php.net erkennen na onderzoek dat gebruikers zijn blootgesteld aan malware. Hackers zouden twee servers zijn binnengedrongen. Die servers zijn buiten werking gesteld en de ssl-sleutel is ingetrokken. Verder moeten Php.net-gebruikers hun wachtwoord resetten.

Donderdag bleek dat de Safe Browsing-dienst malware had aangetroffen op de Php.net-site, waardoor diverse browsers de site blokkeerden. Aanvankelijk werd de melding als false positive bestempeld maar al snel bleek dat er daadwerkelijk tijdelijk een gemanipuleerd javascript-bestand geserveerd werd. Na onderzoek claimen de beheerders van Php.net dat een klein aantal gebruikers de malware tussen 22 en 24 oktober voorgeschoteld kreeg.

Uit dat onderzoek bleek ook dat er twee servers getroffen waren door een hack. Het ging daarbij om het systeem dat de www.php.net-, static.php.net- en git.php.net-domeinen hostte en de server die bugs.php.net huisvestte. De betreffende diensten zijn overgezet naar nieuwe servers. Nog onduidelijk is hoe de hackers de systemen wisten binnen te dringen.

Wel wijzen de beheerders erop dat de hackers mogelijk toegang hadden tot de private sleutel van het ssl-certificaat van Php.net. Het betreffende certificaat is inmiddels ingetrokken. Het team achter Php.net benadrukt dat tarball-downloads en de Git-repository niet zijn getroffen. De komende dagen moeten Php.net-gebruikers hun wachtwoord wijzigen.

Reacties (45)

[Xieoxer]

Ik ben vooral benieuwd om wat voor soort malware het ging en welke OS'en besmet kunnen worden. Voor mijn werk en hobby bezoek ik PHP.net dagelijks en ik zit niet te wachten om malware te verwijderen van mijn computers. Weet een Tweaker dat toevallig?

[Reactie gewijzigd door Xieoxer op 23 juli 2024 17:00]

[MadEgg]

Er werd remote content getalden mbv wat obfuscated javascript in userprefs.js. Zie hier: https://news.ycombinator.com/item?id=6604251 voor meer info.

Ik gebruik deze site vrijwel dagelijks, maar ben ook hier dankzij Firefox plugin RequestPolicy gewoon buiten schot gebleven (al vraag ik mij af of het iets had gedaan op Linux): dit doet gewoon een cross-domain request welke bij mij standaard geblokkeerd worden.

[mloman]

Het gaat om deze malware, die ten tijde van de verspreiding via PHP.net door slechts vijf van de 47 virusscanners werd herkend (nu 17): https://www.virustotal.co...f97d06a8fadefe4/analysis/

[svennd]

Ik denk dat een behoorlijk deel op windows werkt, PHP zelf draait mss wel vaker op een linux systeem.

[Bosmonster]

En dus draai je meestal lokaal ook iets wat een realistische ontwikkelomgeving simuleert.

Maar goed, misschien werk ik in een andere branche, aangezien ik van de tientallen PHP-developers die ik ken, er al jaren niemand meer op Windows ontwikkelt.

[Blokker_1999]

PHP gedraagt zich echt niet anders op Windows dan op een *nix systeem. Het is perfect mogelijk om je PHP scripts te testen op windows zonder een negatief effect te hebben na een verhuis naar een *nix systeem. Enkel wanneer je rechtstreeks gaat ingrijpen op het filesystem met je script moet je oppassen met je paden.

Bijkomend hebben vele editors ook nog eens ingebouwde file transfer mogelijkheden waarbij de file bij elke save gewoon naar een server word gestuurd en anders kan je gelijkaardige functionaliteit bekomen met filesharing opties.

Ik schrijf php zowel onder Windows als onder Linux en heb voor het php devven daar echt geen voorkeur in.

[DJMaze]

En nog maar te zwijgen over case-sensitive paden en spl_autoload

[mrdemc]

Als je altijd werkt met case sensitive paden dan werkt dat op zowel linux als windows. Ligt er dus maar net aan hoe je de code schrijft
Als je gewoon alles netjes afhandeld is er niets aan de hand en werkt het op zowel linux als windows, ook met paden in \ of /. windows kan namelijk in php gewoon met / overweg zoals linux de paden ziet. Enige wat zou kunnen is dat sommige phpmodules niet werken onder windows of andersom zoals ik soms ervaar met specifieke modules. Bij mij echter dat het wel onder windows werkt maar niet onder linux.

[DJMaze]

Ooit met het Zend Framework gewerkt en een autoloader?
[code]new \Zend\AUth()[/code]
Zend Framework heeft CamelCase bestanden en is er een bug die niet zichtbaar is op Windows.

Je kan zeggen dat Zend hierbij fout is omdat zij niet de spl_autoload() routine aanhouden.
Je kan zeggen dat PHP fout is omdat classes case-insensitive zijn.
Je kan zeggen dat Windows fout is omdat de bestanden case-insensitive zijn.

In alle gevallen is het aan jou de taak om het probleem te vermijden:
1. gebruik Zend niet
2. gebruik Windows niet
3. gebruik PHP niet

#2 is dan nog de meest simpele oplossing als je bijvoorbeeld aan een Magento shop moet werken van de opdrachtgever.

Maar ja, dit is allemaal off-topic dankzij Bosmonster

[Reactie gewijzigd door DJMaze op 23 juli 2024 17:00]

[hackerhater]

PHP is weldegelijk anders op Windows dan op *nix. Je hebt alleen wel de geavaceerde features nodig om er tegen aan te lopen.

Makkelijkste voorbeeld : chmod commando, werkt niet onder Windows.
Zo zijn er meer. Dat veel frameworks die verschillen weg abstraheren betekend niet dat ze er niet zijn.

Zodra je serieus gaat samenwerken op een mixed omgeving merk je goed hoe erg Windows gehandicapt is in een *nix omgeving :
- geen native SSH ondersteuning
- geen native SFTP ondersteuning
- geen fatsoendelijke git ondersteuning (zelfs niet met tools)
- case insensitive qua namen terwijl de rest dat wel is
- Niet mogelijk shell scripts (crons!) lokaal te testen
- default gebruikt Windows andere line endings dan de rest
- etc

[Reactie gewijzigd door hackerhater op 23 juli 2024 17:00]

[mrdemc]

Maar andersom uiteraard net zo

[TJVB]

Niet geheel waar.
Sommige functies zijn niet beschikbaar in de Windows versie van PHP. Al zal dit in veel projecten niet gemerkt worden.
Ook ben ik al wel eens problemen tegen gekomen dat een script bestanden in laden wat op windows goed ging. Maar doordat Linux wel hoofdletter gevoelig is met bestandsnamen ging het daar fout.

Maar als het goed is heb je daar altijd een test omgeving voor

[s.stok]

Er is geen native 64bit integer support voor PHP op Windows.
http://marc.info/?l=php-i...als&m=137002754604365&w=2

En Windows heeft een beperking van 255 tekens per path, waar ik geregeld tegen aanloop.
http://msdn.microsoft.com...a365247%28v=vs.85%29.aspx

En Windows heeft geen posix support

Edit. En Windows heeft een vreselijke symlink ondersteuning, je moet Administrator zijn en je kan alleen per lokaal volume een link maken.

[Reactie gewijzigd door s.stok op 23 juli 2024 17:00]

[mxcreep]

Je kunt ook prima PHP devven op een Windows machine als werkstation en een linux doos gebruiken als development server. git of subversion erbij en je hebt een handige oplossing. Op die manier zit je ook niet te klooien met dat developers andere PHP versies lokaal hebben draaien met andere instellingen enzo, gewoon de dev server met dezelfde versie en config laten draaien als de test / produktie servers.

[Reactie gewijzigd door mxcreep op 23 juli 2024 17:00]

[M3!]

Met Vagrant heb je dat ook snel opgelost. Of gewoon een sftp connectie met een dev servertje ergens. Het is meestal ergens een clustertje mensen die op linux werkt, veruit de meeste die ik ken werken op Windows en anders op osx.

[Reactie gewijzigd door M3! op 23 juli 2024 17:00]

[curry684]

Maar goed, misschien werk ik in een andere branche, aangezien ik van de tientallen PHP-developers die ik ken, er al jaren niemand meer op Windows ontwikkelt.

Ik dacht dat je mij ook kende? Iedereen hier in het bedrijf ontwikkelt gewoon op Windows, met een paar Linux devservers om feitelijk te testen. Ik ken juist eigenlijk in mijn grote netwerk geen enkele serieuze software developer die niet merendeel van z'n werk op Windows doet - Macs zie je alleen bij designers, en Linux bij systeembeheerders.

[hackerhater]

Het zal inderdaad aan de branche liggen gok ik.
Het bedrijf waar ik werk zit in de saas-business en wij werken allemaal op Linux of OS X. Te veel gedoe met windows dev machines. Te veel dingen die dan lokaal wel werken, maar op de server niet ed.

Maar zelfs als de mallware ook op Linux gericht was geweest had het me niks gedaan. Lang leven noscript

[Reactie gewijzigd door hackerhater op 23 juli 2024 17:00]

[Yggdrasil]

In mijn ervaring gebruiken de meeste PHP-developers juist Windows. Heb je daar een bron voor?

Overigens is PHP nog steeds een populaire taal, dus zelfs al zou slechts een deel Windows gebruiken dan kunnen er nog steeds veel PC's besmet geraakt zijn door deze malware.

[mcDavid]

Ik denk inderdaad dat het aantal linux-gebruikers onder PHP-developers relatief hoog is, maar relatief hoog zal nog steeds bij lange na geen 50% zijn. Het merendeel van de bezoekers zal ongetwijfeld windows draaien.

PHP.net heeft een visitor stats pagina, maar die is helaas niet beschikbaar of nooit bijgewerkt.

[Rubix]

Ik ben via de detachering bij tientallen bedrijven geweest, en vrijwel niemand gebruikt OS X om PHP te ontwikkelen. Het is voornamelijk Linux en Windows wat de klok slaat.

[riotrick]

Toch zie ook redelijk wat os/x gebruikt worden voor ontwikkelmachines.

Zelf draaien we hier allemaal Windows met zend server op onze ontwikkelmachines.

Alle live servers draaien Linux (vnml debian) met zend server. En we hebben op kantoor ook nog een ontwikkel server met debian en zend server draaien.

Alle applicaties/sites die we ontwikkelen proberen we zo te maken dat ze niet afhankelijk zijn van het onderliggende os. Uiteraard komen er zo hier een daar wat situaties voor dat dat niet of lastig lukt. Maar voor het gros van wat we ontwikkelen maakt het weinig verschil wat het onderliggende os is.

Ontwikkelen op windows en live draaien op linux is dan ook niet echt een probleem.

[P-e-t-j-e]

Windows gebruiker die php-site bewerkt via ftp en op Linux host ;-)... zal dus ook vaak een combi zijn.

[Reactie gewijzigd door P-e-t-j-e op 23 juli 2024 17:00]

[Echron]

Hoe doe jij het dan? Of doel je er op dat FTP niet veilig is en dat er veiligere protocollen zijn voor het overzetten van gegevens?

[Sietse1990]

FTP is inderdaad niet de veiligste manier en hoewel SFTP al beter is, kun je naar mijn ervaring beter SCP gebruiken. Echter is dit niet echt gebruiksvriendelijk en is voor de meeste mensen dus geen optie.

Daardoor denk ik toch dat P-e-t-j-e gelijk heeft. Het merendeel van de programmeurs die ik ken gebruikt gewoon Windows (mede vanwege Visual Studio en veel vraag naar C# in het bedrijfsleven) waardoor ze geen Linux omgeving voor een simpele website gaan draaien. Dus gewoon via FTP naar een server sturen. Deze manier is veel makkelijker en programmeurs zijn graag lui.

Edit: Ik zit te denken waarom de impact per definitie kleiner zou zijn als er bijna geen Windows computers op de website komen. Dan zouden de hackers toch ook nadenken en er Linux malware op zetten. De meeste Linux en OS X gebruikers denken nog steeds dat ze geen virusscanner hoeven te hebben. Geheel onterecht, maar wordt te vaak geroepen.

@mace: Ik bedoelde wel SFTP (FTPS is niet echt meer interessant als je zelf de poorten kunt open zetten). En hoewel dat voor veel mensen de beste oplossing is, is het niet perfect. SCP stuurt data niet als bestanden over, maar via een andere manier zover ik had gevonden. Filezilla heeft ook enkele problemen omdat deze standaard wachtwoorden plain opslaat. Vandaar dat je ook een geschiedenis hebt (wat best fijn is), maar dan moeten ze wel toegang tot je computer hebben om op de server te komen. En als je de user voor de connectie goed afschermt kan het voor de server niet veel kwaad. Maar SCP is niet al te makkelijk. Je moet twee terminals openen en bij één een SCP commando doen en bij de andere moet je vervolgens gewoon inloggen via SSH en het bestand bijvoorbeeld uitpakken. Meerdere bestanden tegelijk sturen werkt niet prettig, iets wat bij SFTP wel goed gaat. Ik update dan ook maar eens in de zoveel tijd mijn systeem online, iets wat bij SFTP makkelijker kan, en eventueel direct met Eclipse en de bijbehorende Remote-plugin.

[Reactie gewijzigd door Sietse1990 op 23 juli 2024 17:00]

[frankwopereis]

Dat ligt eraan wat de intentie van de hack is. Als men Windows wil uitroeien kan je beter geen hack voor Linux of OSX schrijven..

Daarnaast gebruik ik zelf OSX zonder virusscanner. Die had ik op Windows ook nooit, en dat beviel mij altijd prima. Ik had nooit problemen, daar waar mensen met scanners altijd gedoe hadden met virussen, trage pc's en bestanden die in quarantaine werden gezet en vervolgens niet meer benaderbaar waren.

Mijn data is goed gebackupt, en niet gevoelig (bij data diefstal haal ik m'n schouders op), bij een virus knal ik gewoon een nieuw image terug. Voor mij minder gedoe dan een virusscanner.

[mace]

SFTP is prima en beter geschikt voor filetransfers dan SCP.
SFTP is dan ook via SSH, net zoals SCP.

Filezilla ondersteunt het gewoon dus het is voor de meeste gebruikers transparant. Alleen de poort is anders.

Misschien bedoel je FTPS? Dat is FTP via SSL.

[wizzkizz]

Een checkout van je git-repository die je binnenhaalt over SSH met behulp van een deployment key (sleutelbestand) dat je alleen-lezen toegang geeft tot je repository

[P-e-t-j-e]

Tja, ik heb nog geen manier gevonden om een website via draadloze straling op mijn webserver te krijgen... niet iedereen heeft meteen een cms op zijn website bij aankoop, dat moet er eerst op komen te staan.... als je een site met cms wilt...

[Reactie gewijzigd door P-e-t-j-e op 23 juli 2024 17:00]

[haling]

Tja, ik heb nog geen manier gevonden om een website via draadloze straling op mijn webserver te krijgen...

Bosmonster heeft gelijk: FTP is niet meer van deze tijd. SFTP/SSH/SSHFS, etc wel.

FTP verstuurt onversleuteld je gebruikersnaam en wachtwoord over het Internet. 40 jaar geleden kon dat nog.

[P-e-t-j-e]

Kan nu nog steeds hoor... *klik* en voila! :-)

Je hebt wel gelijk maar dat is hetzelfde dat je gaat zeggen dat iedereen die nu pop3/smtp gebruikt (ik ken er misschien wel 100 die dat gewoon doen) 40 jaar achterloopt en overmoet op pop3-ssl en smtp-sll. Er zijn genoeg providers die dat niet eens ondersteunen.

Ben het dus wel met je eens dat waar mogelijk het beter gebruikt kan worden!

[devil-strike]

Sommige devs zijn ook niet bij de tijd aangezien je ook gewoon ssl/tls beveiliging kan gebruiken via ftp.

[TweakerCarlo]

Windows + Notepad++ ftw (just for editing)

[Reactie gewijzigd door TweakerCarlo op 23 juli 2024 17:00]

[Arietje]

Ik ben toch wel benieuwd naar de oorzaak. Of er gebruik is gemaakt van een bug binnen bepaalde software, of dat er middels malware bij beheerders wat fout is gegaan.

[styno]

Is ook bekend welke browsers en/of plugin versies gevoelig waren voor deze hack? In de vele links in deze en vorige berichten over de PHP.net hack wordt daar nergens vermelding van gemaakt.

Edit: Tweakers heeft hier een nieuw bericht voor geplaatst.

[Reactie gewijzigd door styno op 23 juli 2024 17:00]

[DeTeraarist]

Dus eerst melden dat het om een false positive gaat, er dan achter komen dat je toch gehackt bent, dan niet weten hoe ze zijn binnengekomen, maar dan wel acties ondernemen welke mogelijk niets oplossen. Had van php.net toch wel iets beter verwacht.

[timvisee]

Enorm irritand, wanneer de ongeveer 100 searched die je uitvoort die dag (naar PHP pagina's) geblocked worden door google met het bericht, "deze site bevat malware ga terug". Dan kan je handmatig alle links uit de zoekresultaten gaan invoeren in je adresbalk.

[Mausz]

Het is mij niet duidelijk of het nu gaat over gebruikers of bezoekers ? (aangezien ze het over een password reset hebben, betekend dat dat alleen de gebruikers met een account mogelijk besmet zijn?)

[Twazerty]

Zouden ze nog op een oude versie van PHP hebben gedraaid?

[sanderv]

En waar het ook precies aan gelegen heeft, het straalt toch slecht af op PHP als programmeertaal, en de veiligheid daarvan. Ik bedoel dus helemaal niet dat PHP zwak in veiligheid zo zijn, ik denk dat het vooral aan de implementaties ligt die er mee gedaan worden, maar niet iedereen zal het zo zien en stigma's zijn moeilijk kwijt te raken. (Ik hoor nog steeds af en toe het verhaal dat Java traag is, om even een voorbeeldje van zo'n misplaatst vooroordeel te geven.)

Edit:
Voor de goede orde, ik heb het over de negatieve perceptie, en dit is geen waardeoordeel over PHP zelf.

[Reactie gewijzigd door sanderv op 23 juli 2024 17:00]

[JoannisO]

Als PHP als taal onveilig was zouden naar mijn idee veel meer websites zijn getroffen door dit lek. Maar het geld in iedere programmeertaal zo dat de programmeur het systeem zowel veilig als onveilig kan maken.

Ik denk niet dat het veel effect heeft op hoeveel PHP wordt gebruikt en hoe men er naar kijkt.
Bestaande PHP programmeurs gaan voor zo'n ongeval nog niet van taal switchen en nieuwe programmeurs hebben veel hulp aan deze taal en alle resources die er over beschikbaar zijn. Als dit het geval was zou Java nu dicht tegen zijn dood aan zitten wat naar mijn idee niet het geval is.

[Mellow Jack]

Dat vind ik wel een heel gevaarlijke uitspraak!