Tendentieuze vertaling van een niet heel hoogdravend stukje met een aardige noviteit (en met dikke vette plug voor zichzelf).

Wat niemand hier en daar weet op te merken is dat regexen uit untrusted data halen de eerste rode vlag moet zijn. Verder is de php preg_replace "eval" optie (die verder gewoon gedocumenteerd is) op zichzelf al een beveiligingsgat en daarom is die functie niet "onschuldig" te noemen. Qua analyse laten deze bloggers steken vallen, en de vertaling nog meer.

@10:34 - Als geinteresseerde in exif data en ook security vind ik de combi zeer interessant.
Echter, ik snap van het artikel 'niets', het aangehaalde artikel geeft ook geen handvaten tot een concrete voorstelling van hoe één en ander dan zou (kunnen) werken.

Ik vermoed dat er een overlap zit in jouw (ge-mis)punt en mijn onbegrip, maar ook hiermee kom ik geen steek verder.
Nog tijd over om dit 'in één klap op te lossen' met een verhelderende / stapsgewijze toelichting (the way it works)?

- Bijvoorbeeld welk ander programma stuurt/roept het aan buiten de photoview/edit programma of een browser?
- Bezit het de malware al of bevat het alleen code die malware via c&c nog binnen moet halen (opgelost dan met firewall setting op fotoviewer/editor?)
- Van welke code of crossplatform (?) taal kan het gebruik maken.
- Zou het op alle platformen kunnen werken; Windows, Linux, Mac,. .
- Geldt misbruik alleen voor de metavelden ; make , model?
- Kan ik bij het inzien van exifdata de code herkennen onder deze velden? (exiftool is een aardig programma voor inzien metadata).

Gezien het feit dat je vrijwel niet om het gebruik van jpeg afbeeldingen heen kunt lijkt me dat voor een brede groep mensen interessant.
Ben benieuwd,

Het via eval (of soortgelijke) optie uitvoeren van PHP-code is geen bug of lek, maar een feature. Dat preg_replace hier 'bij' kan is verrassend en daardoor inderdaad een kwetsbaarheid.

Maar om nu te zeggen, zoals dit artikel stelt, dat EXIF een backdoor biedt slaat nergens op. De geevalueerde code kan net zo goed in een ander type bestand zitten...

Alsnog benieuwd naar de details.

Zeg maar of het volgende je vertelt wat je weten wilde:


De code leest exif data uit een (specifiek, geprepareerd) plaatje. Dit is zeg maar het transport om de achterdeur naar binnen te krijgen. Eenmaal binnen wordt de achterdeur inelkaar gezet door een onderdeel van de exif data als regular expression te gebruiken (tweede argument) op een ander onderdeel (eerste argument). Er wordt hier vreemde, onvertrouwde data als regular expression gebruikt. Conclusie: Het tweede argument aan preg_replace mag dus nooit "ergens anders" vandaan komen.

Die combinatie levert een resultaat op wat als php code wordt geinterpreteerd. Er bestaat namelijk een optie (/e) die je aan een regular expression kan plakken waarmee de preg_replace dat doet. Dat op zich maakt de functie gevaarlijk. Er wordt hier dus code uitgevoerd die slinks in een geprepareerd plaatje gestopt is.

Die code blijkt uit het uitpakken van base64 data te bestaan (de tweede uitpakronde, de eerste was dat regex-gerommel), met daaromheen nog maar een eval(). Dus wat er in die base64 data staat wordt ook nog eens uitgevoerd na het uitpakken.

En wat staat er in die base64 data? Een instructie om te kijken of er een http-post-parameter "zz1" bestaat, en zo ja die uit te pakken ("stripslashes"), en een derde eval.

Waarmee de achterdeur dus zo werkt dat je een pagina waar'ie in zit aanroept met een specifieke parameter. Die parameter stop je php code in, en die voert'ie dan uit. Dus om een url als http://example.com/hier/is/de/achterdeur.php?zz1=phpcode() (maar dan als POST, niet als GET) vragen voert "phpcode()" uit.

Daarmee is preg_replace niet onschuldig te noemen wegens het bestaan van die "/e" vlag, en moet vreemde en dus onvertrouwbare data als regular expression inzetten onmiddelijk rode lichten laten branden en sirenes doen loeien. De significantie van het plaatje is dat daar het venijn in verborgen zit, zodat het zichtbare gedeelte van de achterdeur maar uit twee onschuldig-ogende functieaanroepen bestaan.


Andere programmas zullen vaak niet eens naar de exif data kijken, of zich wellicht verslikken in wat er in staat. Het plaatje is specifiek voor dit doel geprepareerd, door de gewenste velden de gewenste waarden te geven. Het is ook niet belangrijk wat er in dat plaatje staat of zelfs hoe een browser het laat zien--best kans dat dat nergens gebeurt. Het is alleen maar de verpakking.

Het plaatje hoeft alleen maar ergens te staan waar die exif_read_data()-aanroep erbij kan. Volgens de handleiding: Mag geen URL zijn, dus ergens op het bestandssysteem waar de php draait. Dat is ook het geval in het voorbeeld. Wellicht dat je met een regel extra een plaatje van elders kan halen en die lokaal opslaan, maar dat maakt de zichtbare code weer ingewikkelder.

Deze achterdeur is vrij specifiek php, gezien alle code in php is geschreven. Werkt overal waar php werkt. Dat is dus windows, linux, mac, ... zolang er maar php op draait. En al goed, er moet ook exif support aanwezig zijn.

Dit is niet specifiek afhankelijk van jpeg, het zou kunnen werken met alle formaten waar exif_read_data() exif data uit kan lezen. Wellicht dat je het ook met andere velden zou kunnen doen, maar dat mag iemand die exif beter kent dan ik vertellen.

Deze specifieke truuk detecteren is een ding, maar zo in z'n algemeen exif data doorspitten is iets heel anders. Je zou, bijvoorbeeld, kunnen zoeken op velden die eindigen met "/e", maar wellicht dat "/ei" of "/ue" ook wel goed genoeg werkt en dan kijkt je detectie er toch ineens overheen.

Beste Anoniem 16:12,

Zeer bedankt voor je uitgebreide uitleg.
Technisch nog steeds (voor mij te) hoog maar globaal heb ik wel een idee van het kader waarbinnen de logica van de één tweetjes / één twee drie-tjes zich afspelen .

De afbeelding werkt dus eigenlijk als intermediar c.q. trigger.
Onder Mac Os X zijn Apache en Php (en ook Perl/Ruby) standaard voorgeïnstalleerd, de eerste twee zijn in ieder geval niet standaard geactiveerd.

Om Php aan te roepen zou zowel Php als Apache (?) dan dus eerst geactiveerd moeten worden via de httpd.config. *
En wèl onder een account met Root/Admin privileges!

Of dat zou dan weer via een andere intermediar geactiveerd moeten worden, misschien mogelijk met Java (staat uit / is verwijderd hier) of met Python via een mogelijk Open Office malware script? Open Office routes in de gaten houden denk ik zo (oa gerecycled BadBunny proof of concept?).

Geen logische weg dus, want via Java en geloof ik ook met behulp van Python zou in ieder geval een Mac geïnstrueerd kunnen worden om een remote verbinding te openen en extra code op te halen (afhankelijk van je Java config en je firewall port settings / connection whitelist settings)?

Vooralsnog lijkt daarmee de exif route via php niet de meest logische om te bewandelen.

Java heb ik inmiddels wel onder controle, achter de oren blijf ik mij krabben bij de mogelijke kracht van Python (en toch ook een niet up to date Perl/Ruby, gebruik het ook niet).
Python wordt in tegenstelling tot Java, op bijvoorbeeld een Mac voor diverse programma's aangeroepen en is daarmee heb ik het idee echt onmisbaar.

But thats another story, we zullen zien, nogmaals thanks voor de info.

* Httpd : httpd connectie ken ik op de Mac overigens alleen van een trial met ingeschakelde parental control (wat die verbinding doet en waarom via httpd is me iet helemaal duidelijk overigens, 2e terzijde).

De afbeelding werkt als verpakking zodat de werkelijke achterdeur niet opvalt. De trigger is "wget http://geinfecteerde-site.example.com/hier/is/de/achterdeur.php?zz1=eigen-code-hier()" (ongeveer).

Kunnen triggeren vereist zowel dat de achterdeur ergens ingebouwd zit (niet standaard het geval) en dat de machine die de site-met-achterdeur host bereikbaar is voor de achterdeurgebruiker (en dat'ie dat weet en dat de server aan staat en php aan heeft staan en zo verder).

Het is dus geen algemeen gat in PHP. Ook simpelweg een apache+php geinstalleerd en actief hebben is niet genoeg. Ook is het geen algemeen gat in exif, dat staat in mijn eerdere uitleg. Het is wel een voorbeeld van een doelbewust ergens ingebouwde achterdeur.

De door de achterdeur naarbinnengelaten code wordt uitgevoerd met de gebruiksrechten van het php proces (apache/mod_php: die van apache). En is dus zelf php code die in het php proces wordt uitgevoerd. Of een aanvaller daar verder nog weet uit te breken? Dat ligt er maar net aan wat'ie precies door de achterdeur binnenschoffelt. Het hoort niet te kunnen, maar wellicht weet'ie iets wat wij niet weten. Is dus niet te zeggen.

Maar wellicht was dat helemaal niet de bedoeling. Alleen al (schrijf)toegang op eventuele achterliggende databases kan al erg interessant zijn. De mogelijkheid allerlei toegangsrestricties en invoercontroles te omzeilen. Noem maar op.

Of je dit via java, python, ruby, wat-dan-ook kan aanroepen? Waarom maak je je daar druk over?

Beste Anoniem 2200

Thanks again voor de info!

(zouden ze de inmiddels verschenen minnen bij de 1e twee reacties wel zo aardig weer wegplussen ;-) want er kwam iets positiefs uit!)


Ik had gisteren een langer antwoord klaarliggen, maar het simpelse is om een nieuwe link te plaatsen aangaande mijn eksteroog icm Python (die bij voorkeur daar niet in gaat bijten).

https://www.security.nl/artikel/47148/1/Trojaans_paard_infecteert_Windows_en_Mac.html
Maar er zijn een aantal oudere voorbeelden waarin Python een hoofd danwel subrol had; bijvoorbeeld flashfake / flashback virus.

En als meer en meer gebruikers op het gratis office alternatief LibreOffice overstappen (wat zwaar leunt op Python, en gelukkig steeds minder op java dat ik er al handmatig uit had gesloopt) is het een tweetje van een office document en Python goed denkbaar.

Daarom was ik ook benieuwd naar een mogelijk een tweetje met exifdata als photo-editor open + ander programma.
Dat gaat dus niet direct met de php truuk.
En das mooi.