Tweestapsverificatie op cPanel was te omzeilen met bruteforceaanval

Er zit een kwetsbaarheid in cPanel waarmee het mogelijk is tweestapsverificatie van accounts te omzeilen. Er zat geen limiet op het aantal 2fa-codes dat kon worden geprobeerd in het controlepaneel, waardoor via een bruteforceaanval een code kon worden gegenereerd.

De kwetsbaarheid zit volgens de ontwikkelaars in versies 92, 90 en versie 86, en in oudere versies van cPanel & WebHost Manager. Het lek werd ontdekt door beveiligingsonderzoekers van Digital Defense. Het lek maakte het mogelijk om de tweestapsverificatie van cPanel-accounts te omzeilen. De software is populair en wordt op miljoenen websites gebruikt om het beheer van websites en de gebruikers daarvan te regelen. CPanel wordt voornamelijk gebruikt bij hosting- en resellerproviders die de software bij hostingpakketten aanbieden.

Volgens de onderzoekers van Digital Defense was het mogelijk de tweestapsverificatiecodes te bruteforcen. Een fout ingevoerde code werd niet gevalideerd als een verdachte inlogpoging, waardoor een aanvaller een onbeperkt aantal 2fa-codes kon uitproberen. Omdat die doorgaans bestaan uit zes cijfers kon dat relatief snel gebeuren. Wel moesten aanvallers daarvoor eerst ook de credentials van de gebruiker in bezit hebben.

De onderzoekers hebben de bug doorgegeven aan cPanel. Dat heeft inmiddels patches uitgebracht. De bug is gerepareerd in versies 11.92.0.2, 11.90.0.17 en 11.86.0.32. De onderzoekers raden gebruikers aan hun tweestapsverificatie niet uit te zetten als tijdelijke oplossing, maar om websitebeheerders te vragen cPanel te updaten.

Reacties (17)

[Luchtbakker]

[security] Fixed case SEC-575: Two factor authentication vulnerable to brute force attack.

[WhatsappHack]

Het is ook stom dat je het oneindig vaak mag proberen, heeft altijd al gemogen ondanks commentaar. Er lijkt ook niet direct een manier te zijn om een tool als CSF dat op te laten pikken, daar het niet geregistreerd wordt als failure.

[sourcecode]

Snap dat ook niet, in directadmin is dat prima in te stellen.

[Wim-Bart]

@WhatsappHack en @sourcecode Goed de tekst lezen...

De bug is dat door gebruik van url encoding in plaats van uri encoding het mogelijk was om dit te doen. De bug zorgde er voor dat een fout nooit als zodanig gezien werd. Wat jullie dus ervaren als zijnde "stom" was juist het resultaat van de bug.

[WhatsappHack]

De kwetsbaarheid zit volgens de ontwikkelaars in versies 92.0.2, 90.0.17 en versie 86.0.32

De bug is gerepareerd in versies 11.92.0.2, 11.90.0.17 en 11.86.0.32

@TijsZonderH Wut?

[TijsZonderH]

Ah ik las het inderdaad verkeerd in de release notes, heb het aangepast!

[WhatsappHack]

Top, thanks

[Skix_Aces]

De onderzoekers raden gebruikers aan hun tweestapsverificatie niet uit te zetten als tijdelijke oplossing

Zou ook stom zijn als je dat wel doet. Zoals eerder al in de tekst staat hebben de aanvallers nogsteeds een wachtwoord nodig om je account binnen te komen. Een lekke tweestapauthenticatie is beter dan geen tweestapauthenticatie.

[thunder7]

Dat kon doordat de cPanel-interface aan url-encoding deden voor de 2fa-codes, in plaats van uri-encoding.

mist hier nog een laatste stukje zin?

[SeenD]

Technisch gezien mag er nog een komma bij. Maar de zin is verder goed.

Dat kon doordat de cPanel-interface aan url-encoding deden, voor de 2fa-codes, in plaats van uri-encoding.

Je kan dat eventueel melden bij feedback rechtsboven onder de auteur. Dan kom je hier uit: Geachte Redactie

[Reactie gewijzigd door SeenD op 24 juli 2024 15:52]

[Piemol]

Verschil tussen uri met een i en url met een l encoding:
Difference between uri and url

Al maakt die zin verder mij weinig duidelijk wat het resultaat was.

Dit wel, vanuit de patch notes:

Many cPanel & WHM interfaces create URIs to other interfaces by incorporating user-supplied data in URI query parameters. Several cPanel & WHM interfaces were using URL encoding on these parameters rather than URI encoding. Due to this mistake, a cPanel & WHM user could be misled into performing actions they did not intend

[Reactie gewijzigd door Piemol op 24 juli 2024 15:52]

[Gustinos]

nee toch?

[FrankHe]

Het blijf erg jammer dat er nog steeds dergelijke - wat mij betreft domme - fouten in veelgebruikte systemen zitten. Ik bedoel, heeft daar echt niemand bij stilgestaan? Waar is deze fout erin geslopen? Tijdens de ontwerpfase? Dacht de coder met grote stappen lekker snel thuis te zijn? Heeft er iemand bij de code review zitten slapen? En is dit vervolgens bij een audit ook niet naar boven gekomen? Ik vind het allemaal erg knullig.

[mvrhrln]

Welcome to the realworld
Opleveren daar draait het soms om, hoe en wat komt dan op de 2e plaats,
Is dit goed? nee.

[FrankHe]

Mee eens wat betreft 'reguliere functionaliteit'. Nieuwe features, leuke en handige dingen, kunnen wat mij betreft redelijk ongestraft in een release terechtkomen. Het is immers een publiek geheim dat gebruikers zeer regelmatig, vaak zonder dat ze het zelf weten, nieuwe toepassingen aan het beta-testen zijn.

Maar wanneer het aankomt op functionaliteit die echt 'de kern' vormt van een security feature dan zou je toch verwachten dat men daar iets zorgvuldiger mee omgaat. Hoe dan ook, fijn om te horen dat het issue gefixed is.