PwnScriptum: PHPMailer - Remote Code Execution

 ( toMpEr | 2016. december 26., hétfő - 20:05 )

PHPMailer - "Probably the world's most popular code for sending email from PHP! Used by many open-source projects: WordPress, Drupal, 1CRM, SugarCRM, Yii, Joomla! and many more"

The vulnerability could potentially allow (unauthenticated) remote attackers to  execute arbitrary code and gain unauthorised access to a target web server hosting a web application which uses a vulnerable version of PHPMailer. To exploit the vulnerability attackers could target common website features such as contact forms, password reset, registration forms and others that send emails by using one of the affected versions of PHPMailer.

http://pwnscriptum.com/


Bar a PoC embargos, de a github changelog alapjan eleg konnyen kitalalhato, hogy akkor hasznalhato ki, ha az email feladojat tudja a felhasznalo modositani.

Ami elsore elegge ritka esetnek tunhet, de valojaban elegge bevett szokas, hogy pl webshop rendeles leaadaskor a webshop/contact form uzemeltetojenek is kuld egy emailt a rendelo emailcimevel feladva.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A changelog alapján egy plusz email validáció és egy escapeshellarg() került rá a feladó mezőre. Remélem annyira azért nem elterjedt user input alapján beállítani egy email feladóját, mint amekkora hírverés van most ekörül. Ráadásul a PHP safe_mode -ot is ki kell kapcsolni, hogy ráfusson a szkript arra az ágra, ahol a mail() függvénynek átadásra kerül ez a paraméter, szóval már eleve sok sebből vérzik az az oldal ahol ez problémát okoz.

Ennyiből azt mondanám hogy nem érint, de ami miatt mégis figyelemmel fogom követni, az a mail() függvény doksijában fellelhető sor:
This parameter is escaped by escapeshellcmd(additional_parameters (optional)) internally to prevent command execution.

Ha a sebezhetőség valós és tényleg távoli kódfuttatást tesz lehetővé, akkor az én értelmezésemben ez nem kizárólag a PHPMailer-t érinti, hiszen a mail()-nek meg kellene fognia a rosszindulatú paramétereket.

Szegről-végről kapcsolódó kérdés: létezik manapság valid indok a mail() függvény használata mellett? Gondolok itt arra, hogy pikk-pakk használható SMTP kliensek évek óta léteznek PHP-hoz.

Rendes indokot nem tudok, de a lustaság és a működik-ez-jóvanúgy két igen nyomós gyakrolati érv szokott lenni sajnos.

Nem sok. A felemlegetett Drupal is max. 3rd party modul formájában használhatja. A core kód nem tartalmazza:

https://www.drupal.org/psa-2016-004

--
trey @ gépház

Ha nagyon lightweight mail küldési céljai vannak a programnak, és nem akarsz berántani egy függőséget, akkor hasznos még a mail().

Úgy tűnik nem sikerült tökéletesen a fix: PHPMailer < 5.2.20 Remote Code Execution (0day Patch Bypass/exploit)

$mail->SetFrom("\"Attacker\\' -Param2 -Param3\"@test.com", 'Client Name');

will result in the followig list of arguments passed to sendmail program:

Arg no. 0 == [/usr/sbin/sendmail]
Arg no. 1 == [-t]
Arg no. 2 == [-i]
Arg no. 3 == [-f\"Attacker\\\]
Arg no. 4 == [-Param2]
Arg no. 5 == [-Param3"@test.com']


An attacker could pass the -X parameter of sendmail to write out a
log file with arbitrary PHP code. 

This makes the current latest 5.2.19 and 5.2.18 versions of PHPMailer 
vulnerable to Remote Code Execution despite the patch.

The researcher also developed an Unauthenticated RCE exploit for a popular 
open-source application (deployed on the Internet on more than a million servers)
as a PoC for real-world exploitation. It might be published after the vendor has 
fixed the vulnerabilities.

Ebből én azt sejtem, hogy akkor nem egy újkeletű sebezhetőségről van szó, hanem erről: https://www.saotn.org/exploit-phps-mail-get-remote-code-execution/