Lek in vBulletin-forumsoftware gevonden

Een recente versie van de populaire forumsoftware vBulletin bevat een fors lek, waardoor bezoekers eenvoudig login-gegevens voor de database kunnen achterhalen. De ontwikkelaar heeft een patch vrijgegeven die het gat moet dichten.

Het lek bevindt zich in de faq-pagina van versie 3.8.6 van de forumsoftware. De ontwikkelaars zouden daar zijn vergeten om debug-code te verwijderen. Volgens de BBC is een exploit niet ingewikkeld en zou een gemiddelde gebruiker de gegevens eenvoudig kunnen bemachtigen. Met de login-gegevens van de database zou in theorie een administratoraccount bemachtigd kunnen worden.

Internet Brands, de maker van de software, heeft een patch uitgebracht die het lek moet dichten. Ook heeft het bedrijf een bericht naar de admin-pagina's van alle vBulletin-fora gepusht met een link naar de update. Het is nog niet bekend hoeveel fora de upgrade al doorgevoerd hebben. Volgens Internet Brands maken meer dan veertigduizend online communities gebruik van vBulletin.

Reacties (38)

[Soldaatje]

Je zal als beheerder maar net even op vakantie zijn, kom je thuis owow website gehackt!

[Jan_V]

Sowieso een beetje riskant als er maar 1 beheerder zou zijn.
Kan net zo goed tegen een boom aanrijden.

[Kees]

En waarom zou een klein forum, voor bijvoorbeeld een sportvereniging meerdere administrators nodig hebben?

Als jij de enige bent die een beetje verstand van dit soort dingen heeft in je vereniging, en de rest lukt het maar net om zich te registreren, dan lijkt het me logisch dat je niet meerdere administrators nodig hebt. Ook op een forum als GoT hebben we maar een zeer beperkt aantal mensen die echt een probleem als deze zouden kunnen oplossen.

[DarkKnight]

Ach, ik gok dat er genoeg mensen zijn op tweakers.net/GoT die gebruik kunnen maken van bijvoorbeeld een vergelijkbaar lek als in het artikel om dan het probleem op te lossen als er geen administrators aanwezig zijn

[Cronax]

probleem met 1 admin treedt al op als de admin zijn wachtwoord kwijtraakt of perongeluk zijn eigen admin rechten afneemd oid, maar ik zie je punt wel.

[mimic]

Er zijn wel meer fora die lekken hebben. Zo bijzonder is dit toch niet? Oké, het is slecht dat er debug-code is achtergelaten, maar dit is toch wel een vrij veel voorkomend probleem. Waar mensen werken worden fouten gemaakt. Altijd.

[TimeVortex]

De nieuwswaarde zit dan ook meer in de ernst van het lek. Aangenomen dat het bericht klopt en inderdaad gemakkelijk inloggegevens buit kunnen worden gemaakt, is het beter dat dit nieuws snel de aandacht van vBulletin-forumbeheerders bereikt, vind ik.

[firefly112]

in de vorige versie was het ook heel makkelijker je moest gewoon een query in de search veld type en je kreeg netjes alle gebruikers met wachtwoorden uitgerold

Edit:
ik zij vorige versie ik bedoel paar versies tereug weet niet meer welke het was maar het was iedergeval erg handig om het forum van school me te hacken

[Reactie gewijzigd door firefly112 op 23 juli 2024 23:43]

[Freezerator]

Nou dan ben ik wel benieuwd welke versie dat is geweest want het is jaren geleden dat er z'n bug in vBulletin zat. Wat ook belangrijk is om te melden dat alleen versie 3.8.6 kwetsbaar is, andere versies niet. Maar het blijft meer dan slordig en het is typisch voor vBulletin sinds het overgenomen is door Internet Brands. De kwaliteit van de software (4.x releases) is achteruit gegaan...

[Verwijderd]

Dat is dan wel heel erg lang geleden. Vbulletin gebruikt al jaren passwordhashes die gesalt zijn met een unique hash. (ja echt..) Rainbowen is dan ook nagenoeg niet te doen. Collisions zou nog mogelijk zijn maar de kans dat je er een vind is verwaarloosbaar.

[Verwijderd]

Qua professionaliteit schiet je nog wel iets te kort als "consultant". Op een vrij grote website met naam en toenaam bekennen dat jij het forum van je school gehackt hebt? Verstandige keuze!

Hoewel ik de historie van vBulletin niet ken, lijkt het mij erg stug dat in een versie vanaf 1.0 (Laten we even van een hele oude versie uitgaan) iets simpels als een SQL injectie via een search field mogelijk was. Zelfs zonder enige programmeer ervaring kun je bedenken dat je userinput als deze moet sanatizen eer je het in je queries gebruikt. Vooral in commerciële software. Ik heb ook even een aantal security sites er op na geslagen en nergens kan ik iets vinden over SQL injections via een search field.

[tukkerpaddy]

Hij is systeembeheerder, consultant is slechts een nietszeggende toevoeging.

[Y0shi]

Jammer dat de link naar de methode hierbij niet wordt vrijgegeven. Altijd wel leuk om te weten hoe dit soort dingen inelkaar steken.

De snelle reactie (naar wat ik zie dan) is erg fijn voor onderhouders van deze software. Vindt dit echt een goede ontwikkeling,

[CodeCaster]

Daar zijn zat sites voor, zoek op zero day exploits

Gelukkig leggen veel sites het nogal abstract uit, zodat niet elke scriptkiddie een kant-en-klaar script heeft om sites te gaan hacken.

[Petervanakelyen]

Kan niet zo direct iets vinden op oa inj3ct0r, meest recente dateert van 18 april 2010.

[we_are_borg]

Ik gebruik zelf ook versie 3.8.6 en ze hebben een announcement gemaakt op hun forum en ook gepuched naar de admincp. De email met de waarschuwing kwam pas 24 uur later aangezien de persoon die het ging versturen niet wist hoe hij de mailinglist moest bedienen.

[xiphoid]

we are borg, kom je ook overal tegen he (ben Floris) Ja, de patch is uit, klanten hebben bericht gehad, en een kind kan 3.8.6 exploiten als hij niet gepatched is. Ondertussen is het nieuws hiervan op bbc/theregister en nu ook tweakers alweer. Meestal maken programeurs fouten, maar deze is wel heel slordig, helemaal omdat het bedrijf loopt te adverteren met een Quality Assurance team, etc. Hun versie 4.0.2 had 5 patch releases nodig voordat ze naar 4.0.3 gingen. Voor mij persoonlijk is het duidelijk, vB is niet meer wat het was, en ik wacht gewoon braaf op nieuwe speler in de markt die weet wat ze doen, en begrijpt wat klanten willen, en o.a. de kennis hebben van wat verwacht wordt van moderne oplossingen met huidige en komende web.

[SinergyX]

met de login-gegevens van de database

Natuurlijk heeft elke scriptkiddy deze natuurlijk bij de hand..

Maar je kan toch ook de FAQ nog steeds uitschakelen, daarmee zou je toch al 'gedicht' zijn?

[Kees]

Nee, je kan de logingegevens van de database achterhalen door dit lek, en vervolgens kun je de administrator wachtwoorden opzoeken in de database.

Je hoeft ze dus niet van te voren al te weten

[SinergyX]

Aaah inderdaad, helemaal verkeerd gelezen

[Moartn]

Als je je site goed beveiligd hebt, heb je niets aan de username/password van de database, want dan zorg je ervoor dat directe database-toegang gewoon dicht staat natuurlijk.

[Xthemes.us]

Sterker nog, zover ik weet gebeurd dit al met de standaard instellingen. Ik heb me nog even achter het oor moet krabben voordat ik wel een remote MySQL connectie kon opzetten met mijn eigen server.

(de zover ik weet is omdat ik de standaard installatie uit de standaard openSUSE repositories heb getrokken waar zij de instellingen aangepast hebben - zo is standaard ook het gebruik van .htaccess files onder apache2 disabled).

[YopY]

Op zo'n moment ben ik blij dat mijn licentie(s) verlopen zijn en ik niet meer mag updaten, .

vBulletin / Jelsoft (hebben ze hun naam veranderd?) mag wel wat meer doen aan kwaliteit, met goeie automagische tests zou dit gewoon te voorkomen zijn.

Maar het product zelf ben ik sowieso niet echt blij mee - qua code is het gewoon antiek bijna, ook nog in vB 4 die overstapt op MVC volgens hun zelf. Ook de backend is gewoon tien jaar oud en wordt niet veel meer aan gedaan.

[Freezerator]

Ze zijn overgenomen door Internet Brands (IB) dus dat is de naamsverandering.
De 4.x release is gewoon niet wat het beloofd is. De 3.8.6 was de 1e patch release voor IB sinds ze de overname deden, dus dat belooft veel goeds

[Ilya]

Recente versie? Inmiddels zitten ze toch al op 4.0.5 ofzo?

[frickY]

Met een beetje geluk kun je niets met die database gegeven, en zijn ze alleen geldig voor lokale verbindingen.
Tenzij er ook nog eens een tool zoals phpmyadmin openstaat natuurlijk...

[fdh]

"De ontwikkelaars zouden daar zijn vergeten om debug-code te verwijderen."

Eigenlijk toont dit nog een andere fout aan.

Debug code zou je niet mogen / moeten verwijderen voor de applicatie in productie gaat.
Bij problemen in productie is het juist heel handig als je één of andere parameter kunt aanzetten waardoor debugging logfiles aangemaakt worden (of zelfs op het scherm getoond worden ingeval van web applicaties).

Als een klant problemen heeft dan moet je enkel vragen om de parameter(s) te enablen en de logs door te sturen om te kunnen beginnen.

Wel geen goed idee om passwoorden in de debugging output te steken natuurlijk