Admin, if you have not applied the security patches for the recent vBulletin Zero Day exploit, see

https://thehackernews.com/2017/12/vb...m-hacking.html

The following is a transcript from a security podcast that I rely on for news concerning malicious software;

-====================-

Two Critical 0-Day Remote Exploits for vBulletin Forum Disclosed Publicly
https://thehackernews.com/2017/12/vb...m-hacking.html
Web forum systems have long been difficult to secure. Since they inherently allow remote users
to submit posts that are then stored, parsed by the server and displayed on everyone else's
browsers, there has always been ample opportunity for miscreants to discover clever ways to
compromise those systems. (This is why GRC's forthcoming web forums were built on a
physically separate machine with its own firewall and independent network to the Internet. I
cannot risk anything getting loose from GRC's forum software and into the rest of GRC's internal
network. So there is full physical and network isolation in place.)
The situation on the online forum front have become much better over time, so that major flaws
are becoming more rare as modern forum software has become far more careful about sanitizing
what it accepts from unknown posters. But as we know, mistakes still happen, and vBulletin,
one of the granddaddies of the forum systems, has recently had a pair of 0-Day vulnerabilities
disclosed publicly.
The public 0-Day disclosures were deliberately made by researchers out of frustration after the
vBulletin maintainers failed to acknowledge any communications for nearly a month. So this
means that a huge number of vBulletin sites are CURRENTLY vulnerable and, as we know, that
even after vBulletin is updated, many sites are likely to remain vulnerable.
The first vulnerability discovered in vBulletin is a file inclusion issue that enables remote code
execution. A remote attacker is able to include any file from the vBulletin server and execute
arbitrary PHP code against any file installed on Windows OS. The disclosure includes working
Proof-of-Concept (PoC) exploit code to show the exploitation of the vulnerability. A Common
Vulnerabilities and Exposures (CVE) number has not been assigned to this particular
vulnerability.
The second vulnerability has been assigned CVE-2017-17672 and described as a deserialization
issue that an unauthenticated attacker can exploit to delete arbitrary files and even execute
malicious code "under certain circumstances." The vulnerability arises from the unsafe usage of
PHP's unserialize() function on user-supplied input, which allows an unauthenticated hacker to
delete arbitrary files and possibly execute arbitrary code on a vBulletin installation. And here,
too, the advisory includes Proof-of-Concept (PoC) exploit code to demonstrate the severity of
this vulnerability.
Not only is server compromise immediately possible, but anything else running on the same
system might also be at risk and all visitors to and user of the affected forums might become
victims as well.
-====================-



Beverly Howard