Remote code execution-zeroday in forumsoftware vBulletin is online gezet

Een anonieme beveiligingsonderzoeker heeft een zeroday voor vBulletin gepubliceerd. De populaire software om forums te maken had een kwetsbaarheid waarmee het mogelijk was van een afstand code op de betreffende server uit te voeren.

De bugjager plaatste details over het lek op de Full Disclosure-maillijst. De kwetsbaarheid zou in in ieder geval werken op alle versies van vBulletin van 5.0.0 tot en met 5.5.4. Het gaat om een remote code execution-kwetsbaarheid waarmee een aanvaller een HTTP POST-request kan uitvoeren op de server waar vBulletin op draait. Daarvoor is bovendien geen verdere authenticatie nodig. Een aanvaller heeft geen account op het betreffende forum nodig.

Opvallend is ook hoe relatief eenvoudig het lek is uit te buiten. Dat kan al door een commando in te geven in slechts twintig regels Python-code. Verschillende beveiligingsonderzoekers hebben het lek getest en concluderen dat de exploit inderdaad werkt. De eerste kwetsbare versie, 5.0.0, kwam al in 2012 uit.

Er is op dit moment geen patch beschikbaar voor de kwetsbaarheid. De ontdekker geeft naast de werking van de exploit weinig details over hoe hij het lek op het spoor kwam. Ook is niet duidelijk of hij aan responsible disclosure heeft gedaan en vBulletin eerst heeft ingelicht, of dat hij het lek zomaar online heeft gezet. vBulletin zelf heeft nog niet gereageerd.

De software van het bedrijf wordt gebruikt door enkele grote bedrijven. Het goedbezochte Bodybuilding.com-forum en de forums van Steam, EA, Sony en de NASA draaien op vBulletin.

Reacties (50)

[TheBorg]

Daarom schakel ik in de php.ini altijd functies zoals shell_exec uit.

disable_functions = dl, exec, shell_exec, system, passthru, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, pfsockopen, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid

De meeste software heeft deze functies toch niet nodig.

[Reactie gewijzigd door TheBorg op 23 juli 2024 04:24]

[n9iels]

Ik zou het liever nog anders verwoorden: deze functies zou je nooit nodig moeten hebben op dat niveau van je architectuur. Het direct gebruiken van die functies vanuit een web applicatie is een teken dat er iets fout gaat in je technisch ontwerp. Eigenlijk zou je die dingen specifiek aan moeten zetten.

Als je al systeem commando's wilt uitvoeren hoor je dit netjes weg te werken in een andere laag en m.b.v. permissions enkel toegang geven tot die specifieke commando's. Daarmee voorkom je dat het probleem nog groter wordt dan het al is in het geval van een remote code execution.

[hackerhater]

True this.
Dat je op de cli (cron-job) wellicht nog de shell nodig hebt ok
Maar in je webapplicatie?

[CyberJack]

Uitschakelen is inderdaad het beste, maar mocht software deze functies ooit echt nodig hebben, dan kan je ook nog naar snuffleupagus kijken. Dit is een extensie die deze functies kan limiteren/verbieden.

[Cyb]

Hier stelt iemand de vraag aan vBulletin over het uitschakelen van deze gevaarlijke functies:
https://forum.vbulletin.c...ru-system-shell-exec-exec

De reactie van vBulletin:

Nothing will go wrong with them activated.

exec() wordt gebruikt om ImageMagick uit te voeren, indien ingesteld.
https://forum.vbulletin.c...g-dangerous-php-functions

Wel raar dat ze de technical support lead niet direct een lijstje paraat heeft met of gevaarlijke functies wel/niet gebruikt worden, maar komt met een antwoord als "as far as I am aware".

[n9iels]

Dat is een post uit 2004. Ondanks het nogal onbekwame antwoord niet echt representabel wet betreft hun huidige inzichten.

[Cyb]

niet echt representabel wet betreft hun huidige inzichten

Blijkbaar is het wel representatief voor hun huidige inzichten als je kijkt naar het type blunder wat nu gemaakt is.

In de post van 2013 kon een lead nog steeds geen fatsoenlijk antwoord geven over welke gevaarlijke functies er gebruikt worden.

[Reactie gewijzigd door Cyb op 23 juli 2024 04:24]

[n9iels]

Oke 2013 komt wel wat dichterbij het punt dat je wat bekwaamheid verwacht Ben benieuwd wanneer en hoe ze dit oppakken in ieder geval.

[Cyb]

De exploit zelf is al bizar, maar net zo bizar vind ik dat de exploit in de avond van 23 September gepubliceerd is, en vBulletin nog steeds niets heeft laten horen. Ondertussen zijn er steeds meer meldingen van gehackte vBulletin websites.

https://forum.vbulletin.c...emote-exploit-in-the-wild

edit: vBulletin heeft het topic van de link hierboven uitgeschakeld, en de inhoud is niet meer zichtbaar vanaf buiten. De wijze hoe dit in een soort van doofpot wordt gestopt is evenmin geruststellend.

Wel hebben ze aangekondigd:

Wayne Luke
vBulletin Technical Support Lead
Today, 6:52pm
We will be releasing a security patch for 5.5.2, 5.5.3, and 5.5.4 as soon as possible. The issue is also fixed in the upcoming 5.5.5.

If you are not running vBulletin 5.5.2 or higher, it is imperative that you upgrade your site to the latest available version.

There is a community provided temporary fix in this post here: https://forum.vbulletin.c...day?p=4422617#post4422617

[Reactie gewijzigd door Cyb op 23 juli 2024 04:24]

[gertvdijk]

Ik kijk naar de exploit code, maar dit is amper een exploit te noemen joh. Het is gewoon sturen van shellcode naar een HTTP endpoint in een POST request met een parameter en de server voert dat uit in eval(). In mijn definitie heet dit gewoon 'code execution as a service'.

[SidewalkSuper]

Deze exploit werd al 3 jaar door Zerodium op de markt aangeboden getuige deze tweet.

The recent vBulletin pre-auth RCE 0day disclosed by a researcher on full-disclosure looks like a bugdoor, a perfect candidate for @PwnieAwards 2020. Easy to spot and exploit.

Many researchers were selling this exploit for years. @Zerodium customers were aware of it since 3 years

https://twitter.com/cbekrar/status/1176803541047861249?s=21

[The Zep Man]

Wordt toch tijd dat men wat meer aan invoervalidatie gaat doen. Het is al even geen 1999 meer.

In dit geval is de exploit zo simpel dat je je kan afvragen waarom organisaties zelf niet ook aansprakelijk worden gesteld voor levering van zulke brakke code.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 04:24]

[Niet Henk]

Invoervalidatie is een halve oplossing, te vergelijken met een stuk duct tape over een (potentieel) lek doen en er klaar mee zijn. Dat lek had er in eerste instantie niet moeten zitten, en je kan het beter gewoon dichten, dan weet je dat het houdt.

Je moet gewoon niet invoer als code behandelen. Dus geen eval op variabelen die invoer kunnen bevatten, geen string concatenation voor je SQL strings (maar parameterization), bestanden die gebruikers uploaden apart wegzetten op een plek waar de webserver ze niet gaat uitvoeren, etc.

Natuurlijk is invoervalidatie om te checken dat je gebruikers geen foute data invoeren prima. Maar niet vanwege veiligheid.

[The Zep Man]

Invoervalidatie is een halve oplossing,

Onder 'invoervalidatie' bedoel ik niet alleen controle op de data zelf, maar ook hoe je ermee omgaat. Daar valt bijvoorbeeld validatie van de code ook onder.

Het is niet dat je de invoer van een gebruiker niet moet vertrouwen. Het is meer dat je je programma moet schrijven op een manier dat je nooit op de invoer van de gebruiker hoeft en kunt vertrouwen.

[n9iels]

In dit geval is de exploit zo simpel dat je je kan afvragen waarom organisaties zelf niet ook aansprakelijk worden gesteld voor levering van zulke brakke code.

Omdat het hebben van een security-issue niet direct betekend dat je code brak is. Nu lijkt dit inderdaad wel op een enorme open deur, maar sommige zero-days die uitkomen zijn ook echt nauwelijks te ontdekken bij een al vrij diepgaande code-review. Het aansprakelijk stellen van zo iets is dan vrij lastig, want wanneer is iets "een open deur" en wanneer had je het wel kunnen weten?

[The Zep Man]

Omdat het hebben van een security-issue niet direct betekend dat je code brak is.

Niet bij elke kwetsbaarheid, maar bij deze is het overduidelijk.

Het aansprakelijk stellen van zo iets is dan vrij lastig, want wanneer is iets "een open deur" en wanneer had je het wel kunnen weten?

Je zou voor dit soort gevallen de OWASP top 10 als een leidraad kunnen gebruiken.

[Tozz]

Omdat dat is afgedicht in de gebruiksvoorwaarden.

[Auredium]

Dat is best wel kwalijk, helemaal als er geen patch voor is. Je kunt er vanuit gaan dat in deze dag en tijd er nog voor morgen actief misbruik van wordt gemaakt op grote schaal. Er zullen wel weer een hoop accounts worden gestolen met als gevolg een hoop nieuwe spam en cybercriminaliteit. Het zou leuk zijn als er altijd responsible wordt om gegaan met dit soort exploits.

[Cyb]

Het lek wordt al actief gebruikt.
Elk VBulletin forum zou per direct offline gehaald moeten worden, tot er een patch is of tot er security maatregelen genomen zijn.

Vbulletin heeft nog geen woord over dit grote probleem gerept.
https://forum.vbulletin.c...emote-exploit-in-the-wild

PassMark heeft er ook last van:
https://twitter.com/PassMarkInc/status/1176712135256109056

[n9iels]

Ik snap het persoonlijk ook niet dat je zo iets random in het wil neergooit. Als je met zo een grote exploit naar VBulletin toe gaat is de kans aanwezig dat je er zowel eer als misschien nog wel een kleine vergoeding voor krijgt ook.

Nu is het publiek plaatsten van een exploit nog altijd beter dan het doorverkopen op de zwarte markt aan de hoogste bieder. Maar echt handig kan ik het niet noemen.

[Webgnome]

Mooi schoolvoorbeeld van waarom eval evil is. Je kunt met deze bug dus als je pech hebt een hele server leeg gooien.. rm -rf .

[The Zep Man]

Mooi schoolvoorbeeld van waarom eval evil is. Je kunt met deze bug dus als je pech hebt een hele server leeg gooien.. rm -rf .

Een enkele punt gaat uit van de huidige working directory Beter:
rm -rf /

[Blokker_1999]

En dan probeer je een root dir weg te gooien wat ook niet lukt. Gebruik dan rm -rf /*

[jurroen]

rm --Rf -no-preserve-root /

Werkt op Linux. Unix/Darwin weet ik niet.

[hackerhater]

Dan klopt er toch serieus iets niet met de webserver-permissies.
De hele webspace leeggooien? sure.

[Webgnome]

Dan heb je inderdaad nog een ander probleem dan alleen een foutief stukje code.

[TeraMod]

Helaas moet ik wel eval gebruiken...

1und1 heeft in alle (on)wijsheid besloten de PHP-module imagick uit te schakelen, maar wel imagemagick via de command line (en dus ook eval) beschikbaar te maken.
GD is geen volwaardig alternatief voor mijn usercase.

[veltnet]

tijd voor een andere hoster?

[Webgnome]

Dan is het een kwestie van neem je dat risico? Of ga je naar een andere hoster/omgeving zodat je eval niet hoeft te gebruiken.

[Bart.net]

Dat kan al door een commando in te geven in slechts twintig regels Python-code.

Zo te zien kan het door een enkel post-commando: requests.post( url= *url*, data = {"routestring":"ajax/render/widget_php", "widgetConfig[code]":"echo shell_exec(' *code* '); exit;"})

Werd mogelijk gemaakt doordat er eval($code) werd gebruikt.

edit: laatste toevoeging

[Reactie gewijzigd door Bart.net op 23 juli 2024 04:24]

[MadEgg]

[...]
Werd mogelijk gemaakt doordat er eval($code) werd gebruikt.

Die zou nooit en te nimmer gebruikt moeten worden. Dat het er nog in zit is kwalijk genoeg.

[Douweegbertje]

Technisch gezien is er niets mis met eval. Er zijn zeker logische en valide cases te bedenken waarom het prima is. Onder de developers hangt af en toe een dingetje van bepaalde termen wat super zwart-wit is. Eval is slecht, GoTo slaat nergens op, X-taal is voor noobs, etc etc.

Eindstand is gewoon heel simpel dat er valide zaken zijn, maar dat je net zoals met elke andere functie is niet moet "abusen". Als jij gewoon non-user generated content door je eval haalt, is er letterlijk niets aan de hand. Gegeven is dat je wel hele aparte use-cases hebt en dat 99% van de devs hier helemaal niet mee te maken heeft; desalniettemin is het command op zich zelf niet evil. De consequenties zijn alleen enorm vergaand bij verkeerd gebruik.

Ik heb zelf voor een bepaalde "reken achtige tool" ook evals op een logische manier gebruikt. Bepaalde berekeningen die semi statisch uitgevoerd moeten worden. Dat kunnen bepaalde "blocks" zijn die uiteindelijk door een eval gaan. - Niet gebaseerd op user-input, niet te abusen, en valide voor mijn doel. Had het anders gekund? Jazeker. Zou ik tegenwoordig nog dit soort dingen maken? Nee, niet perse.

[MadEgg]

Je zegt het toch al in je laatste zin? Eval zou deprecated moeten worden zodat gebruikers die het ooit in legacy code hebben geschreven gedwongen worden om het netter uit te werken.

Eval is alleen veilig als je er statische code in doet, zonder variabelen. En dan heeft het weinig zin, want dan kun je de code net zo goed rechtstreeks uitvoeren.

Zet je er wel variabelen in dan moet je kunnen garanderen dat die variabelen nooit en te nimmer ingevuld kunnen worden vanuit externe input. En dat is lastig om te doen en gaat in de praktijk te vaak fout.

Overigens is eval in PHP en andere interpreted languages niet de enige manier. Je kunt ook prima je PHP-code wegschrijven naar een .php bestand en dat bestand vervolgens weer includen in je code.

Er zijn zeker valide use cases te verzinnen waarbij het nuttig is om code runtime te bepalen in plaats van vooraf, maar daar zijn altijd betere manieren voor te gebruiken dan via constructies zoals eval.

[Haruhi]

Gelukkig draai ik VBulletin 3.x.x en vervolgens helemaal zelf maar dichtgetimmerd.

[StefanTs]

Hoe timmer je software die al 2 jaar eol is dicht dan?

[mkools24]

Waarschijnlijk met bijv Cloudflare, modsecurity e.d. maar veilig om oude meuk te draaien is het natuurlijk niet.

[Bosmonster]

Een versie draaien die al ruim 2 jaar End Of Life is. Dat is inderdaad een stuk veiliger.

[mkools24]

Ik heb zelf altijd versie 4 gedraaid tot volle tevredenheid maar na een upgrade naar 5 was ik zo teleurgesteld dat ik snel naar Xenforo ben gegaan en ik ben niet de enige.

[jozuf]

Gelukkig zijn er voor deze versie ook niet een berg aan andere exploits makkelijk te vinden;
https://www.exploitalert....lts.html?search=vbulletin
https://www.google.com/se...&sourceid=chrome&ie=UTF-8

[Haruhi]

Vandaar ook het dichttimmeren.

[jozuf]

Ik denk dat je dat maar tot zover gaat lukken. Je moet dan ook alle SQLi gaten in de code dichten bv.
Kan wel, maar wel erg veel handmatig werk allemaal.

[Jaerie]

20 regels python code is nog veel, het kan met een enkel request met een enkele header en een header met de uit te voeren code, waar in het PoC is gekozen voor een shell_exec, maar je zou alle PHP uit kunnen voeren.

[paradoXical]

Hier zijn zaken als mod_security dan weer handig voor. En ik neem aan dat grote partijen als de NASA wel iets zoals cloudflare of een soortgelijke service gebruiken?