"gevaarlijke" PHP tmp files in c:\windows\temp

[Verwijderd]

Op mijn server draaien een paar websites, deze draaien allemaal op een seperate drive (e drive).
Nou heb ik een APT/IOC scanner trial draaien en deze meldt mij vrolijk dat bepaalde temp files in c:\windows\temp gevaarlijk zijn en bepaalde web shells in zich kunnen hebben.

Nu is het niet zo dat de phptmp files in de E drive voorkomen, en kunnen dus niet geserveerd/gepublished en geexecute worden, echter ik vraag me af hoe men dit soort tmp files kan creeeren.

Ook vraag ik me af wat php ermee doet.

Op de server draait Kaspersky Endpoint Protection, echter Kaspersky ziet er geen kwaad in.

Voorbeeldje
C:\Windows\Temp\php1820.tmp SCORE 124
MAIN REASON ChinaChopper_Generic / China Chopper Webshells - PHP and ASPX Score: +70

C:\Windows\Temp\php131E.tmp SCORE 134
MAIN REASON cknife_webshells_generic / Detects Cknife Webshell Score: +80

[ Voor 5% gewijzigd door Verwijderd op 10-10-2016 22:09 ]

[Ventieldopje]

Als de tmp map die PHP gebruikt niet die map is, dan is er een ander lek waardoor daar bestanden geschreven kunnen worden. Al lijkt het mij stug dat dan daar juist bestanden aan worden gemaakt

- knip offtopic -

[ Voor 35% gewijzigd door .oisyn op 11-10-2016 10:58 ]

[Verwijderd]

Ventieldopje schreef op maandag 10 oktober 2016 @ 22:11:
Als de tmp map die PHP gebruikt niet die map is, dan is er een ander lek waardoor daar bestanden geschreven kunnen worden. Al lijkt het mij stug dat dan daar juist bestanden aan worden gemaakt

offtopic:
Windows is nou niet echt een goed en veilig platform om PHP applicaties op te draaien. Misschien een idee om dit dmv. vagrant / docker onder te brengen in een virtuele omgeving? Dat is een stuk veiliger dan aparte schijven.

De C:windows\temp is inderdaad de juiste map die PHP daarvoor gebruikt. Zo staat het in de php.ini.

[Ventieldopje]

In dat geval is het héél simpel om een tmp bestand te maken:

PHP:

<?php
$temp = tmpfile();
fwrite($temp, "writing to tempfile");
fseek($temp, 0);
echo fread($temp, 1024);
fclose($temp); // this removes the file
?>

http://php.net/manual/en/function.tmpfile.php

Kans is aanwezig dat een website die je draait een lek heeft van het een of ander.

[ Voor 12% gewijzigd door Ventieldopje op 10-10-2016 22:19 ]

[RobIII]

- knip offtopic -

Ventieldopje schreef op maandag 10 oktober 2016 @ 22:18:
In dat geval is het héél simpel om een tmp bestand te maken:

PHP:

<?php
$temp = tmpfile();
fwrite($temp, "writing to tempfile");
fseek($temp, 0);
echo fread($temp, 1024);
fclose($temp); // this removes the file
?>

En dat verklaart die malicious files hoe precies?

Voor wat betreft 't probleem: PHP parkeert uploads in de temp directory tijdens de upload waarna ze doorgaans met een move_uploaded_file o.i.d. op de juiste plek geparkeerd worden. Ik vermoed dat er ergens gewoon een upload script aanwezig is in de website (misschien wat toegankelijker dan bedoeld bijvoorbeeld?). Om wat voor soort websites gaat het hier? Gaat het hier om eigen brouwsels of dingen als WordPress o.i.d.?

[ Voor 48% gewijzigd door .oisyn op 11-10-2016 10:58 ]

[Verwijderd]

Heb net eens even alle oude php tmp bende weggegooid en ga zo even een nieuwe scan draaien. Heb wel al eens in het verleden een gehackte website op de server gehad, wellicht dat daar nog phptmp files van stonden. Sinds die hack heb ik de wp-contents folders geblocked voor php files.

[Verwijderd]

RobIII schreef op maandag 10 oktober 2016 @ 22:28:
[...]

Wat een onzin Kom met (recente, fatsoenlijke) bronnen of zeg gewoon niks.


[...]

En dat verklaart die malicious files hoe precies?

Voor wat betreft 't probleem: PHP parkeert uploads in de temp directory tijdens de upload waarna ze doorgaans met een move_uploaded_file o.i.d. op de juiste plek geparkeerd worden. Ik vermoed dat er ergens gewoon een upload script aanwezig is in de website (misschien wat toegankelijker dan bedoeld bijvoorbeeld?). Om wat voor soort websites gaat het hier? Gaat het hier om eigen brouwsels of dingen als WordPress o.i.d.?

Het gaat in dit geval om meerdere types websites, Wordpress, Joomla, maar ook statische websites. 1 wordpress site was een tijdje geleden gehacked.

[Gomez12]

Is je APT/IOC scanner wel goed? (Zegt mij niets maar ok) Of is het zo'n type scanner wat gewoon 90% false positives genereert? Oftewel heb je een 2e check-mogelijkheid voor die files om te zien of het echt zo is?

Want in principe kan er van alles in je tmp-directory schrijven (immer php kan het) en als jij een heel assortiment aan frameworks (Wordpress/joomla etc) hebt dan is het hopen dat je je php netjes als verschillende users hebt draaien zodat je kan kijken wie de owner van zo'n bestand is en die website is dan de veroorzaker.

Maar het nadeel is dat het ook gewoon false positives kunnen zijn op volkomen legitieme processen (veel processen maken gebruik van tmp voor caching / samenstellen van dingen etc)

[Verwijderd]

Gomez12 schreef op maandag 10 oktober 2016 @ 23:43:
Is je APT/IOC scanner wel goed? (Zegt mij niets maar ok) Of is het zo'n type scanner wat gewoon 90% false positives genereert? Oftewel heb je een 2e check-mogelijkheid voor die files om te zien of het echt zo is?

Want in principe kan er van alles in je tmp-directory schrijven (immer php kan het) en als jij een heel assortiment aan frameworks (Wordpress/joomla etc) hebt dan is het hopen dat je je php netjes als verschillende users hebt draaien zodat je kan kijken wie de owner van zo'n bestand is en die website is dan de veroorzaker.

Maar het nadeel is dat het ook gewoon false positives kunnen zijn op volkomen legitieme processen (veel processen maken gebruik van tmp voor caching / samenstellen van dingen etc)

APT/IOC is Advanced Persistant Threat / Indicator of Compromise. Dit zijn zeer specifieke scanners die naar dingen zoeken die de zelfs de betere virusscanners niet kennen. Nou vermoed ik dat de tmp files obfuscated files waren aangezien er ook een url in stond die de php code kon maskeren. Best geinig allemaal. Inmiddels heeft de scan weer gelopen en niks nieuws gevonden, behalve dingen in de prullenbak, maar dat klopt.

Ik heb overigens niet elke website op een andere user draaien, wellicht ga ik dat nog doen.

[Megamind]

Heb je die temp bestanden ingekeken? Stonden daar vreemde dingen in? Het kan zijn dat de checksum van zo'n bestand een keer is aangemerkt als malicious en het gewoon false positives zijn.

[Verwijderd]

Megamind schreef op dinsdag 11 oktober 2016 @ 02:17:
Heb je die temp bestanden ingekeken? Stonden daar vreemde dingen in? Het kan zijn dat de checksum van zo'n bestand een keer is aangemerkt als malicious en het gewoon false positives zijn.

In de tmp bestanden stond een soort van url waarin je php code kon obfuscaten.
http://www.fopo.com.ar/
Weet niet echt wat hier de bedoeling van is, maar denk dat je dan de php code minder goed kan uitlezen ofzo ?

Heb helaas iets te enthousiast de oude wellicht gehackte phpxxx.tmp files weggegooid, want nu heb ik geen voorbeeld meer.

[ Voor 9% gewijzigd door Verwijderd op 11-10-2016 09:42 ]

[Verwijderd]

HollowGamer schreef op dinsdag 11 oktober 2016 @ 07:20:
[...]

Er zit toch wel een kern van waarheid in; hoewel Windows de laatste jaren is verbeterd in veiligheid, zit er bijvoorbeeld geen package-manager in waardoor libs/apps kunnen achter lopen, iets dat je niet wilt met de lekken de laatste tijd. Met VM's/docker is het gewoon beter te managen, al zul je daar wel kennis van moeten hebben/opdoen.

Niet dat ik Windows wil afschrijven, maar het is misschien niet voor niks dat LAMP een populair begrip is.

Waar heb je die scanner gevonden? Ik vind niks door te googelen.

De gratis versie heet Loki, er is ook een betaalde versie.

https://www.bsk-consulting.de/loki-free-ioc-scanner/

[.oisyn]

En weer open. Discussie over PHP op Windows afgesplitst naar [Disc] Over de (on)veiligheid van PHP op Windows

[ Voor 83% gewijzigd door .oisyn op 11-10-2016 10:53 ]

[hackerhater]

Verwijderd schreef op dinsdag 11 oktober 2016 @ 09:38:
[...]


In de tmp bestanden stond een soort van url waarin je php code kon obfuscaten.
http://www.fopo.com.ar/
Weet niet echt wat hier de bedoeling van is, maar denk dat je dan de php code minder goed kan uitlezen ofzo ?

Heb helaas iets te enthousiast de oude wellicht gehackte phpxxx.tmp files weggegooid, want nu heb ik geen voorbeeld meer.

Dat is sowieso een slecht teken. Opschonen die handel en in de gaten houden.
Gescheiden users had btw niks uitgemaakt tenzij je elke user zijn eigen tmp ruimte geeft wat doorsnee niet gebeurd.

[Verwijderd]

hackerhater schreef op dinsdag 11 oktober 2016 @ 11:02:
[...]


Dat is sowieso een slecht teken. Opschonen die handel en in de gaten houden.
Gescheiden users had btw niks uitgemaakt tenzij je elke user zijn eigen tmp ruimte geeft wat doorsnee niet gebeurd.

Dat lijkt me ook ingewikkeld. Dit is een test server, maar stel je hebt 200/300 websites op 1 server draaien, dan moet je inderdaad allemaal seperate items aanmaken en ook seperate users en app pools assignen op die gebruiker.

[hackerhater]

Betreffende dat dit een test-server is. Waar draait de productie-server op?
Als dat Linux raad ik je ten zeerste af de test op Windows te draaien. Je kan dan namelijk bugs missen.

[Verwijderd]

hackerhater schreef op dinsdag 11 oktober 2016 @ 11:11:
Betreffende dat dit een test-server is. Waar draait de productie-server op?
Als dat Linux raad ik je ten zeerste af de test op Windows te draaien. Je kan dan namelijk bugs missen.

Windows Server 2012 R2. Loki werkt met Windows, maar ik zie ook python staan in de source.
https://github.com/Neo23x0/Loki

[hackerhater]

Oke dat is een goede reden om test ook op Windows te hebben
Je wilt test en productie zo dicht bij elkaar hebben als mogelijk.

Aanvulling:
Als dit een test-server is, waarom zijn de sites dan publiekelijk toegankelijk?
Scherm de server af zodat alleen de testers eraan kunnen.
Dat zal enorm schelen voor de veiligheid

[ Voor 43% gewijzigd door hackerhater op 11-10-2016 13:19 ]