We're jerks and just strip everything down to a-Z space .- and @ _ anything beyond that f u, extensions and 3rd party library or even core filters come out with these vulnerabilities all the time, at least we will know for sure what characters were passed in from the start though I'm sure most business NEED to support every wacky combination but I'll take the complaint over the hack any day.
PHPMailer Exploit – Remote Code Execution
61–70 of 109 posts
Re: PHPMailer Exploit – Remote Code Execution
#62Earlier quoted context omitted.
I am curious why you linked to reddit? There is nothing in the discussion (4 comments) that is not in the linked advisory. Looking back through your comment history you seem to do this a lot, even linking to discussion pages on reddit with no comments whatsoever and the same link as found in the HN submission.
Looks like a bot to me. Literally only pastes links. I'd suspect that some of the websites it links to generate ad-rev, while the wikipedia and reddit links are there to obfuscate the purpose of the bot. It's simple logic. If you notice, both the Reddit and HN source have the same source url.
[deleted]
Re: PHPMailer Exploit – Remote Code Execution
#63Earlier quoted context omitted.
It's times like this I'm glad I have a country block setup through ipdeny. Reducing the likelihood of attack by two orders of magnitude is a big help until there's a patch.
No it is unfortunately not if there exists at least one company that provides a VPN service from your country. :)
You don't think there's any value in reducing penetration attempts by 2-3 orders of magnitude? I went from seeing an attack every few seconds to one per day/week.
Re: PHPMailer Exploit – Remote Code Execution
#64Per the writeup, it looks like they were already escaping their arguments, but they didn't know PHP's built-in mail() function was already doing that: PHPMailer 5.2.17 sanitizes the $Sender variable by applying escapeshellarg() escaping before the value is passed to mail() function. It does not however take into account the clashing of the escapeshellarg() function with internal escaping with escapeshellcmd() perform…
> It looks like better documentation could have prevented this bug.
Where?
Barring user-submitted comments, PHP has consistently had some of the most complete programming language documentation.
This exact issue is specifically documented with the mail() function[1] so I'm not sure you can blame PHP or ask for better documentation in this case:
"This parameter is escaped by escapeshellcmd() internally to prevent command execution. escapeshellcmd() prevents command execution, but allows to add additional parameters. For security reasons, it is recommended for the user to sanitize this parameter to avoid adding unwanted parameters to the shell command."
Escaping too many times or incorrectly is a pretty common error but it's normally of the PEBKAC variety.
Re: PHPMailer Exploit – Remote Code Execution
#65PHPMailer is also used by wordpress: https://www.wordfence.com/blog/2016/12/phpmailer-vulnerabili...
Stock wordpress shouldn't be remotely exploitable with this. The exploit relies on the end user being able to specify the "From" address. That is passed to sendmail via the -f parameter on the command line, which is why the vulnerability exists. Other addresses, like To:, are passed via the headers/piped, so they don't create issues.
Wordpress is adding a fix, but I assume that's to cover plugins that allow end users to set the From: address, like perhaps "Share this with a friend" type functionality where the email is meant to look like it's from a different domain.
In short, I don't think most wordpress installations are remotely exploitable via this bug.
Re: PHPMailer Exploit – Remote Code Execution
#66Per the writeup, it looks like they were already escaping their arguments, but they didn't know PHP's built-in mail() function was already doing that: PHPMailer 5.2.17 sanitizes the $Sender variable by applying escapeshellarg() escaping before the value is passed to mail() function. It does not however take into account the clashing of the escapeshellarg() function with internal escaping with escapeshellcmd() perform…
> It looks like better documentation could have prevented this bug. Where? Barring user-submitted comments, PHP has consistently had some of the most complete programming language documentation. This exact issue is specifically documented with the mail() function[1] so I'm not sure you can blame PHP or ask for better documentation in this case: "This parameter is escaped by escapeshellcmd() internally to prevent comm…
You're right. I retract the documentation comment.
Re: PHPMailer Exploit – Remote Code Execution
#67Per the writeup, it looks like they were already escaping their arguments, but they didn't know PHP's built-in mail() function was already doing that: PHPMailer 5.2.17 sanitizes the $Sender variable by applying escapeshellarg() escaping before the value is passed to mail() function. It does not however take into account the clashing of the escapeshellarg() function with internal escaping with escapeshellcmd() perform…
> In those cases, it really isn't a good idea to send mail in-process anyway due to web-process and SMTP timeouts
Why is sending a message to something like RabbitMQ less likely to timeout then to postfix?
Re: PHPMailer Exploit – Remote Code Execution
#68Earlier quoted context omitted.
No it is unfortunately not if there exists at least one company that provides a VPN service from your country. :)
You don't think there's any value in reducing penetration attempts by 2-3 orders of magnitude? I went from seeing an attack every few seconds to one per day/week.
How do you monitor attacks?
Re: PHPMailer Exploit – Remote Code Execution
#69Out of curiosity, why is PHPMailer invoking the command line at all? It would seem much safer to establish a TCP connection to the local MTA over port 25 or 587 and send the message that way. Admins can just use iptables to restrict access to the port to localhost, and/or do the same in their MTA config.
It's using PHP's builtin mail() function, which happens to be a wrapper around /usr/bin/sendmail, and one of the parameters it takes is used as an "additional command-line parameter to sendmail". In particular, the "-f" switch is used to set the SMTP envelope MAIL FROM address. Apparently PHP's mail() tries to do some automagic shell escaping on the argument but it's likely not good enough and it also creates a confl…
Software should never be using -f with user emails, regardless if it's sanitized or not. -f sets the return path, which will trigger DMARC protection if the domain doesn't allow it. For example, the yahoo.com policy will reject all mail if you try to set the return path to the user's yahoo.com address using -f.
The best way I've found to send mail on behalf of someone else is to leave the return path (-f) and From header pointing to your own domain, and use the Reply-To header with the users email.
Re: PHPMailer Exploit – Remote Code Execution
#70PHPMailer is also used by wordpress: https://www.wordfence.com/blog/2016/12/phpmailer-vulnerabili...
It's times like this I'm glad I have a country block setup through ipdeny. Reducing the likelihood of attack by two orders of magnitude is a big help until there's a patch.
Nice.
What countries do you block..?