WHMCS has had serious issues in the past with code execution,
https://www.cvedetails.com/vulnerability-list/vendor_id-10798/Whmcs.html
this is likely the provider just trying to avoid issues while using this
system. Many years back there was a nice exploit involving hiding php
shells inside PNG data chunks and that could be triggered via resizing and
other functions which led to the hacking of some forum software,
https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/
, in today's exploit world anything can be mundane at first then later
weaponized by some secondary payload/process this concept has been shown
with egghunter where arbitrary data is appended into a request as just
ascii then later transforms into shellcode, another case involved a person
that could use some clever AES transformations that could turn a wallpaper
into a payload apk just with AES decrypt on android,
http://securityaffairs.co/wordpress/29438/security/hiding-malicious-android-apk.html
So even if an attachment seemed safe there could be risk that it can be
transformed later into something else. Though, in this case I think it's
more about the provider using WHMCS and the issues it had in the past, so
they likely setup this policy to reduce some of those vectors of attack.
-Mystagic
On 10 September 2016 at 20:01, Ronald F. Guilmette <rfg at
tristatelogic.com>
wrote:
>
> Maybe an ignorant question, but hopefully not an outright stupid one...
>
> The story:
>
> As I was interacting with my new VM provider, there was a problem.
> And I had to send the provider a captured screenshot of the browser
> window where something had gone ugly wrong.
>
> I managed to get the screenshot as a .png file, and was all prepared
> to attach it to a follow-up message that I was sending to the provider
> through the providers's ticket system, which is apparently based on
> WHMCS (which I confess I know nothing about).
>
> Anyway, the try as I might, the ticket system kept refusing to allow
> me to attach *any* attachment to my messages. I kept giving me the
> following utterly moronic and useless error message:
>
> The following errors occurred:
> * The file you tried to upload is not allowed.
>
> Subsequent queries to the provider elicited the following explanation:
>
> "Oh, the attachments are disabled as a security precaution -
it's
> unfortunate, but WHMCS doesn't actually 'check' attachments
for
> malicious files, so it's a potential point of compromise."
>
> Now, please understand everybody, as a general matter I actively _avoid_
> using Windoze whenever possible. I'm proud to say that (a) I've
never
> in my life read a single email message of my own on any Windoze system
> and also (b) that I've never yet been hacked. (And yes, I do believe
> that there may be a relationship between these two facts.)
>
> My point is that I've never found it necessary to understand in any
> depth what sorts of attachments could possibly do damage, e.g. if
> opened in the Wrong Environment. My abundant ignorance gives rise
> to the following seemingly simple and obvious question:
>
> After all these years, and after thousands or millions of different
> types and strains of malware having been seen in the wild, is there
> really still no readily available tool that can simply be given a hunk
> of data, sent as an email attatchment, and which can successfully
> remove from that hunk of data any and all "active" elements,
components,
> or sub-parts which might even potentially cause damage in any arbitrary
> environment?
>
> If not, then perhaps I just invented the next billion dollar start up.
> :-)
>
> But seriously folks, if the first few bytes of a file say that it is
> just a plain old ordinary .png file, then why would anybody or anything
> live in fear of it? It's just a bloody image file for God's sake!
>
> Ok, so I just googled around and found some articles describing some
> reports of "exploits" ostensibly relating n some way to .png
files.
> But drilling down into those shows that really, all that is actually
> happening here is that the attackers are using certain parts of .png
> files... e.g. the tail end or the metadata fields... to smuggle in
> _other_ bad stuff _after_ the attacker has already gotten control in
> some other way.
>
> So it seems that whereas .png files can be used for smuggling in evil
> data, they can't really be used for primary exploitation. On that
> basis alone I have no idea why anyone would ever think that it would
> ever be of any use at all to block them. But even if the thought
> of receiving a .png file makes you shrink in horror, why not just build
> a tool which inspects the bloody things and which strips out any of
> the unnatural/evil/smuggled content, leaving behind just an utterly
> harmless toothless actual image file?
>
> I tried googling for "attachment disinfection" but it appears
that most
> or all of the hits I get are to do with water purification and/or other
> biology-related subjects.
>
> So seriously, nobody ever built an attachment disinfector?
>
>
> Regards,
> rfg
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at
freebsd.org
> "
>