Er is een lek gevonden op je website! Of toch niet?

Als hostingprovider zien we steeds vaker dat klanten e-mails ontvangen over vermeende veiligheidslekken in hun website. Soms gaat het om waardevolle bevindingen, maar regelmatig om standaardfunctionaliteit die ten onrechte als ‘kritiek beveiligingslek’ wordt gepresenteerd. In deze blog leggen we uit wat het verschil is tussen een échte bug bounty en een zogenaamde beg bounty, en hoe je kunt herkennen wanneer je alert moet zijn.

 

Wat is een bug bounty?

Een bug bounty is een legitiem programma waarbij beveiligingsonderzoekers beloond worden voor het verantwoord melden van échte veiligheidslekken. Grote bedrijven zoals Google, Microsoft en Facebook hebben officiële bug bounty-programma’s waarbij ethische hackers kwetsbaarheden kunnen rapporteren in ruil voor een beloning.

Kenmerken van een serieuze bug bounty-melding:

• Professionele toon en gedetailleerde technische documentatie waarin een concreet technisch probleem wordt aangetoond
• Duidelijke impact en exploitatie-scenario’s, bijvoorbeeld data lekken, rechten omzeilen, code uitvoeren, etc.
• Verantwoorde disclosure (eerst privé melden, niet publiekelijk: er gewacht met publicatie tot het probleem is opgelost)
• Geen directe vraag om betaling vooraf
• Verwijzing naar erkende kwetsbaarhedendatabases (CVE’s)

Dit soort meldingen zijn waardevol. Ze helpen software en websites veiliger te maken.

 

Wat is een beg bounty?

Een beg bounty (bedel-bounty) lijkt op een bug bounty, maar is dat niet. Het is een poging om geld te verdienen door standaardfunctionaliteit of zeer laagrisicogedrag als ernstig beveiligingslek te presenteren. Het doel is eigenaren bang te maken zodat ze betalen voor ‘het verhelpen’ van een probleem dat er eigenlijk niet is.

Kenmerken van een beg bounty:

• Overdreven ernst (‘high severity’, ‘critical’, ‘serious vulnerabilities’) bij triviale bevindingen
• Standaardfunctionaliteit wordt gepresenteerd als lek
• Directe of subtiele hints naar betaling
• Generieke meldingen die met één tool massaal verstuurd worden
• Vaak wordt verwezen naar algemene security-artikelen
• Weinig begrip van de daadwerkelijke impact

Het doel is meestal niet veiligheid verbeteren, maar geld verdienen met half-waarheden.

 

Een klassiek voorbeeld: WordPress user enumeration

Een veelvoorkomende melding gaat over deze URL:

De melding stelt dat het WordPress REST API endpoint /wp-json/wp/v2/users/ een ernstig beveiligingslek is omdat het gebruikersnamen onthult.

 

Voorbeeld van de inhoud van de mail over WordPress user enumeration

Onderwerp: Sensitive Data Exposure

Hello there,

I have found some serious vulnerabilities on your website apart from these and would like to get it to your attention as soon as possible.

Vulnerability:
Target: https://jouwdomeinnaam/
Vulnerability: User Enumeration via REST API
Severity: Medium to High (Credential Harvesting & Brute Force Support)

Summary:
I have identified that the WordPress REST API endpoint located at https://jouwdomeinnaam/wp-json/wp/v2/users/ is publicly accessible without authentication. This endpoint discloses a list of valid usernames such as “jouw naam” and others, which can then be leveraged by attackers to target your login interface (/wp-login.php) in brute-force, password spraying, or credential stuffing attacks. Since WordPress does not enforce restrictions on this endpoint by default, the disclosure of this data creates a serious reconnaissance advantage for malicious actors.

Steps to Reproduce (PoC):
1. Navigate to: https://jouwdomeinnaam/wp-json/wp/v2/users/
2. Perform a standard GET request from any browser or API tool (e.g., Postman, cURL)
3. Observe that the server responds with a list of user objects, including id, name, and slug values
4. Note that slug corresponds directly to valid usernames used on the login page
5. These usernames can then be used in brute-force attempts against the login panel at https://jouwdomeinnaam/wp-admin

Impact:
By exposing valid usernames, attackers can drastically reduce the complexity and time required to perform a successful brute-force or password spraying attack. Instead of having to guess both the username and the password, they can focus entirely on breaking known credentials. If administrative accounts are revealed and successfully attacked, this could lead to a full compromise of the website — allowing modification or deletion of content, access to sensitive data, privilege escalation, malware installation, and disruption of site availability.

Recommendations:
To mitigate this issue, the /wp/v2/users/ endpoint should be restricted from public access unless explicitly required. You can disable this endpoint by adding a filter in the functions.php file of your WordPress theme or by using a custom plugin. Here is a recommended code snippet:

add_filter( ‘rest_endpoints’, function( $endpoints ) {
if ( isset( $endpoints[‘/wp/v2/users’] ) ) {
unset( $endpoints[‘/wp/v2/users’] );
}
if ( isset( $endpoints[‘/wp/v2/users/(?P<id>[\d]+)’] ) ) {
unset( $endpoints[‘/wp/v2/users/(?P<id>[\d]+)’] );
}
return $endpoints;
});

Reference:
https://nvd.nist.gov/vuln/detail/CVE-2017-5487
https://owasp.org/www-community/attacks/Brute_force_attack

 

Waarom is dit géén kritiek beveiligingslek?

1. Het is standaardgedrag: WordPress maakt gebruikersnamen standaard publiek zichtbaar. Dit is een ontwerpbeslissing, geen bug. Gebruikersnamen verschijnen in artikel-URL’s, auteurspagina’s en RSS-feeds.
2. Gebruikersnamen zijn geen geheimen: In WordPress-architectuur zijn gebruikersnamen nooit bedoeld als vertrouwelijke informatie. De beveiliging rust op sterke wachtwoorden en aanvullende maatregelen zoals two-factor authentication.
3. De CVE-referentie klopt niet helemaal: CVE-2017-5487 verwijst naar een specifieke kwetsbaarheid in oude WordPress-versies. Het algemene gedrag van de REST API is geen CVE-waardige kwetsbaarheid.
4. De impact is minimaal: Met moderne beveiligingsmaatregelen (rate limiting, sterke wachtwoorden, 2FA, login-bescherming) is het kennen van een gebruikersnaam onvoldoende voor een succesvolle aanval.

 

Een interessante ontdekking

Uit nieuwsgierigheid bekeek ik de website van de afzender zelf. Wat bleek? Ook daar was het /wp-json/wp/v2/users/ endpoint gewoon actief en toegankelijk. Precies hetzelfde gedrag dat als ‘serious vulnerability’ werd gemeld.

Dit onderstreept nogmaals dat het hier gaat om standaardgedrag van WordPress, niet om een specifiek beveiligingslek in één bepaalde site. Als dit werkelijk een kritieke kwetsbaarheid zou zijn, zou je verwachten dat een beveiligingsonderzoeker dit eerst op de eigen website zou hebben verholpen.

Daarnaast was bij de melder ook de standaard WordPress-inlogpagina gewoon bereikbaar via zowel /wp-admin als /wp-login.php. Juist in zo’n situatie zou user enumeration in combinatie met een publiek toegankelijke loginpagina een verhoogd risico kunnen vormen.

Maar zodra je de loginpagina verbergt of extra beveiligt, iets wat wij standaard aanraden,  heeft een aanvaller weinig aan eventueel gevonden gebruikersnamen. Ons advies: verplaats de standaard WordPress-loginpagina naar een andere locatie of beveilig deze met bijvoorbeeld IP-whitelisting. Dit voorkomt brute-force-aanvallen, maakt user enumeration irrelevant en haalt de meeste geautomatiseerde scanners direct de wind uit de zeilen.

 

Hoe gevaarlijk zijn dit soort meldingen echt?

In 90% van de gevallen is het:

• geen hack
• geen directe kwetsbaarheid
• geen reden tot paniek
• geen melding die actie vereist

Veel van deze ‘vondsten’ zijn standaard WordPress‑gedrag. Het risico is laag, zeker als:

• je sterke wachtwoorden gebruikt
• je inlogpagina verborgen is
• je 2FA hebt
• je login wordt beschermd door rate limiting of een firewall
• WordPress, thema’s en plugins up-to-date zijn

De meeste beg bounties zijn dus ruis.

 

Wanneer zou de melding uit het voorbeeld wél een zorg zijn?

Er zijn situaties waarin je dit endpoint wilt uitschakelen:

• Je hebt gebruikersnamen die gevoelige informatie bevatten
• Je wilt een extra beveiligingslaag door obscurity
• Je draait een membership-site waar privacy extra belangrijk is

Maar dan nog is het geen ernstige kwetsbaarheid die onmiddellijke actie vereist.

 

Herken de signalen: wanneer wél serieus nemen?

Neem een melding serieus wanneer deze betrekking heeft op echte kwetsbaarheden, bijvoorbeeld:

• SQL-injectie: mogelijkheid om database-queries te manipuleren
• Cross-Site Scripting (XSS): injectie van kwaadaardige scripts
• Remote Code Execution: mogelijkheid om code uit te voeren op de server
• Authentication bypass: omzeilen van inlogbeveiliging
• Data leakage: onbedoelde toegang tot klantgegevens of wachtwoorden
• Ongepatched software: verouderde CMS-, plugin- of themaversies met bekende kwetsbaarheden

 

Let daarnaast op een professionele presentatie:

• Concrete proof-of-concept met screenshots of video
• Duidelijke reproductie-stappen
• Realistische impactbeoordeling
• Geen haast of druk om te betalen
• Vermelding van responsible disclosure

 

Wat te doen bij een veiligheidsmelding?

Of het nu om een legitieme bug bounty of een beg bounty gaat, wij stellen het zeer op prijs als je deze meldingen doorstuurt naar ons supportteam. Waarom?

1. Wij kunnen de ernst inschatten: ons technisch team kan beoordelen of er daadwerkelijk een risico is
2. Wij herkennen patronen: als meerdere klanten dezelfde melding krijgen, kunnen we daar sneller waarschuwen en reageren
3. Wij kunnen je ontzorgen: je hoeft je geen zorgen te maken of je wel of niet moet betalen
4. Wij kunnen helpen met échte problemen: als er wél een kwetsbaarheid is, kunnen we je helpen deze snel en effectief te verhelpen.

 

Ons advies

Wel doen:

• Stuur de melding direct door naar ons
• Vraag om een second opinion voordat je reageert of betaalt
• Houd je WordPress, plugins en thema’s up-to-date
• Gebruik sterke wachtwoorden en two-factor authentication
• Overweeg extra beveiligingsmaatregelen zoals login-bescherming en firewalls

 

Niet doen:

• Direct betalen uit angst
• Persoonlijke gegevens delen met onbekende afzenders
• In paniek raken bij termen als ‘critical’ of ‘high severity’
• De melding negeren zonder deze te laten checken

 

Conclusie

De grens tussen bug bounty en beg bounty kan soms dun zijn. Terwijl beveiligingsonderzoek waardevol is en aangemoedigd moet worden, zijn er helaas ook opportunisten die standaardfunctionaliteit presenteren als kritieke lekken.
Als klant hoeft je je hier geen zorgen over te maken: stuur elke veiligheidsmelding die je ontvangt gewoon naar ons door. Wij kunnen in enkele minuten beoordelen of het om een serieus probleem gaat of om een beg bounty, en je adviseren over de beste vervolgstappen.
Samen houden we je website veilig, zonder onnodige kosten of zorgen.