Exploit WordPress opent mogelijkheid wachtwoordreset te onderscheppen - update

WordPress Core bevat een kwetsbaarheid waarvoor nog geen patch is en die het onder omstandigheden mogelijk maakt voor aanvallers om wachtwoorden van gebruikers een reset te geven en zo toegang tot de accounts te krijgen.

Kwetsbaarheid CVE-2017-8295 heeft betrekking op alle versies van WordPress, waaronder de recentste, versie 4.7.4. Het probleem zit hem in de manier waarop WordPress de resetmails opstelt, claimt Dawid Golunski van Legal Hackers, die een toelichting op de kwetsbaarheid geeft via ExploitBox.

WordPress verkrijgt de hostnaam voor de From/Return-header van de resetmail via een SERVER_NAME-variabele, beschrijft Golunski. "Sommige grote webservers, zoals Apache, stellen de SERVER_NAME-variabele in op basis van de hostnaam die de client heeft ingesteld", zo licht de onderzoeker toe. Dit opent mogelijkheden voor een aanvaller om de variabele aan te passen naar een ander domein en de resetlink in de mail te onderscheppen.

Als mogelijk scenario noemt Golunski het uitvoeren van een dos-aanval op het e-mailaccount van het slachtoffer, zodat de resetmail een bounce krijgt naar het domein van de aanvaller. Ook zou een slachtoffer overgehaald kunnen worden een reply te sturen, bijvoorbeeld na het meerdere keren laten versturen van resetmails, waarop het doelwit mogelijk tekst en uitleg wil.

Er is nog geen patch beschikbaar al kunnen gebruikers een tijdelijke work-around inschakelen door het gebruik van UseCanonicalName, waarmee een statische SERVER_NAME-waarde wordt gegenereerd. Golunksy stelt WordPress al sinds juli 2016 meerdere keren op de hoogte te hebben gesteld, zonder succes. Ook via HackerOne kwam er geen schot in de zaak, waarop hij besloot te publiceren.

Update, maandag, 8 mei, 13.00: Een patch is nog niet beschikbaar maar er zijn wel patches voorgesteld in het betreffende Trac-item voor Wordpress Core.

Reacties (78)

[Foamy]

"Sommige grote webservers, zoals Apache, stellen de SERVER_NAME-variabele in op basis van de hostnaam die de client heeft ingesteld", zo licht de onderzoeker toe.

Dit hoeft natuurlijk niet het geval te zijn.. Zoals je in de documentatie van deze functionaliteit kunt lezen (https://httpd.apache.org/...ore.html#usecanonicalname) zijn er ook instellingen mogelijk waarbij dit "lek" geheel niet op kan treden.

Daar komt ook nog bij kijken dat er meerdere zaken mis moeten gaan wil de aanval kans van slagen hebben:

• De server van het doelwit moet dusdanig zijn ingesteld dat deze het accepteerd dat de client de SERVER_NAME variabele aanpast.
• De WordPress installatie van het doelwit moet de mails "as-is" versturen. Als de site zelf de From: headers aanpast, of zet dan werkt dit al niet meer
• Je moet op de een of andere manier de mail laten bouncen, inclusief het originele bericht in de bounce. Als de server van de ontvanger dit niet doet dan hang je (alweer)

In mijn optiek is dit meer een theoretische mogelijkheid dan een daadwerkelijk lek. En op basis daarvan snap ik ook wel dat er iets minder prio aan de fix is gegeven.

Voor meer info, hier ook het Trac ticket dat er bij WP zelf voor loopt: https://core.trac.wordpress.org/ticket/25239

Oh, en met een filter zoals:

add_filter( 'wp_mail_from', function( $from_email ) { return '[e-mail]'; } );

in je thema of een plugin ben je dus al niet meer vatbaar voor dit lek

[Reactie gewijzigd door Foamy op 24 juli 2024 12:55]

[b2vjfvj75gjx7]

Exact dat - ik gebruik dat al jaren om misbruik van je headers te voorkomen...

FUNCTIONS.PHP

// default mail-adress for wp-actions

add_filter( 'wp_mail_from', function( $from_email ) {

return WP_MAIL_FROM;

} );

WP-CONFIG.PHP

// default mail-adress for wp-actions

define('WP_MAIL_FROM', '[e-mail]');

Op die manier definieer je voordat WordPress wordt gebootstrapped (nee, niet díe Bootstrap...) de standaard 'from' client en met een hook parse je die vanuit je custom template in de core.

- edit - WP codex : https://codex.wordpress.o...er_Reference/wp_mail_from

[Reactie gewijzigd door b2vjfvj75gjx7 op 24 juli 2024 12:55]

[Douweegbertje]

Er zijn ook zat cases waarbij het perfect uitgevoerd kan worden, als zijnde weerwoord op al jouw argument waarom het weer niet zou kunnen.

Veel cases zoals configs, filters e.d. zijn standaard niet aanwezig. Daarbij kan het goed voorkomen dat het e-mail adres verkeerd is geconfigureerd waardoor je instant al een bounce krijgt. Nog maar niet te spreken over out of office meldingen met een "reply". Collega's die reply-all doen met een vraag aan een collega "was jij dit?" en ga zo maar door.

Ik snap heus wel dat dit niet pertinent alle WP sites finaal om zeep helpt maar desalniettemin is dit een serieuze flaw en het is een kwestie van enkele uren voordat de eerste geautomatiseerde bots langs komen met de malafide requests (als dat nog niet het geval is).

Stel dat in een edge-case 0.1% vatbaar is, dan spreek je alsnog over een zeer groot aantal websites.

[dimitrivisser]

Er zijn ook zat cases waarbij het perfect uitgevoerd kan worden

Je overdrijft het verschrikkelijk. WIl je deze hack uitvoeren dan moet je eerst met een DOS aanval een emailprovider platleggen voordat je de password reset aanvraagd. Het probleem is echter dat je eerst het emailadres moet weten dat bij een bepaalde gebruiker hoort. Voor scriptkiddies houd het dan al op.

Out of officemeldingen ? Bij ons wordt de msg niet gequote. Collega's die een persoonlijk emailtje naar mijn werkadres beantwoorden met een reply "was jij dit?" ? Een Wordpress admin die zijn email fout heeft ingevuld ?

Ik heb echt het idee dat je te ver doordraaft. Die 0,1% haal je nooit zo.

[-J00P-]

Ik vind het echt bizar hoe jij (en sommige andere reacties) deze kwetsbaarheid bagatelliseren. Het feit dat het risico op misbruik laag is zegt niets in dit geval. Voor de enkele keren dat het gebeurt kunnen de gevolgen enorm zijn. Een wachtwoord is de sleutel tot iemands digitale identiteit.

Bovendien overschat je hoe ingewikkeld het is om een dos uit te voeren. Er zijn voldoende sites (zgn booters) waar je voor een paar euro per uur een botnet kan bestellen.

Deze kwetsbaarheid heeft de potentie om een hoop schade aan te brengen.

[dimitrivisser]

Serieus, niet praktisch uitvoerbaar.

Als mijn server een email aflevert dan probeert hij dat een paar dagen, ik geloof 48 uur. Daarna gaat het mailtje terug naar diegene die het heeft verstuurd. Als jij met een dos aanval op een email provider de aflevering van het emailtje wilt verhinderen dan moet je een email provider dus 48 uur platleggen met een dos aanval.

Ik heb gmail. Ik wens je veel succes ;-)

Hacks van Wordpress websites gebeuren altijd door scriptkiddies, die duizenden websites proberen in de hoop dat er 1 een foute plugin gebruikt of dat er 1 zijn bestandsrechten niet goed heeft ingesteld. In dit geval moet je eerst het emailadres hebben dat past bij de loginnaam van het account dat je wilt hacken. Dat vereist voorkennis, je moet de persoon min of meer kennen. Vervolgens een dos aanval 48 uur lang. En dan nog heb je kans dat het niet werkt. Da's een veel te grote investering voor de personen die zich bezig houden met het hacken van wordpress websites.

[Douweegbertje]

Ik draai niet te ver door. Ik snap echt 100% goed wat de implicaties zijn. In mijn functie ben ik ook verantwoordelijk voor de security e.d. en heb ik een inschatting moeten maken.

Uiteindelijk heb ik ook even gekeken hoe het nu precies werkt. Ten eerste hoef je helemaal niet het e-mail adres te weten. Simpelweg een user OF emailadres. Een user is nog relatief simpel omdat je vaak genoeg blogs hebt waar je de users kan inzien.

Simpele API call: /wp-json/wp/v2/users
Tada.. de username.

Als je vervolgens een payload stuurt dan zal hij het defacto e-mail adres gebruiken. Ik heb dus een site met het admin e-mail adres: "[e-mail]". De e-mail wordt domweg verstuurd vanuit "[e-mail]".

Dit is zo simpel te automatiseren. Ik snap ook nog wel dat je er dan niet bent, maar nogmaals heb je zoveel cases waardoor je een email server niet plat hoeft te leggen voor 5 dagen (dat hij dan pas bounced) vanwege:
- verkeerde configuraties
- Oude emails die gelijk al bouncen
- user errors

Je vergeet dat het hier niet gaat om een specifieke target op 1 website. Ja dan is deze 'bug' enorm lastig uit te voeren. Het feit dat er zoveel WP sites zijn maakt het echter wel een enorm vervelende exploit omdat het je gewoon wat oplevert als je dit automatiseert.

Ik vind het te bizar dat iedereen argumenten loopt te "verzinnen" om het maar te relativeren terwijl ik zo 10 sites kan pakken waar ik nu toegang tot kan krijgen. Omdat toevallig die van jou er niet tussen zit, stelt het maar niets voor. Goede insteek!

[dimitrivisser]

Uiteindelijk heb ik ook even gekeken hoe het nu precies werkt. Ten eerste hoef je helemaal niet het e-mail adres te weten. Simpelweg een user OF emailadres. Een user is nog relatief simpel omdat je vaak genoeg blogs hebt waar je de users kan inzien.

Je moet een emailadres hebben. Voordat je de password reset aanvraagd moet je namelijk eerst de email server van je slachtoffer met een dos aanval platleggen. En dat 48 uur lang volhouden zodat de email bounced. De enige manier om dat te doen zonder een emailadres is om alle mailservers op de hele wereld plat te leggen, en dat 48 uur lang volhouden.

Natuurlijk is het mogelijk dat ik weet dat jij een wordpress website hebt, en dat ik jouw emailadres ken. Maar dit vereist wel voorkennis. Iets dat scriptkiddies die duizenden websites testen niet hebben. Daarnaast moet je jouw email niet op dezelfde server hosten als je website, wat bij 99% van de Wordpress websites waarschijnlijk wel zal zijn. Want dan zal het platleggen van de email server er namelijk ook voor zorgen dat de website geen password reset kan afhandelen.

Serieus... Deze exploit maakt mij niet bang. Ik heb tientallen Wordpress websites en heb vanacht prima geslapen ;-)

[mobrockers]

Als je tientallen wordpress websites beheerd en prima kan slapen dan kan ik me inderdaad voorstellen dat je hier ook niet wakker van ligt ;-)

[thePiett]

Er zullen wel meer webapps deze variabele op deze manier gebruiken. Jammer dat het halve internet op Wordpress draait

[Asitis]

Daarom deste vervelend dat zo'n melding genegeerd lijkt te worden. OK, WordPress stamt uit een verzameling rommelige codes, maar is toch de laatste jare ndruk bezig met het gelijk trekken van de hele core, en heeft als doel om een strak, schaalbaar CMS te worden. Dan zijn dit soort meldingen toch je top prioriteit zou je denken...

[Rob]

Genegeerd wordt het niet, maar er wordt teveel gepraat en te weinig gedaan : https://core.trac.wordpress.org/ticket/25239

[Asitis]

Golunksy stelt WordPress al sinds juli 2016 meerdere keren op de hoogte te hebben gesteld, zonder succes. Ook via HackerOne kwam er geen schot in de zaak, waarop hij besloot te publiceren.

[FvdM]

Het artikel is inmiddels aangepast naar exploit.

[jozuf]

Dus duidelijk ook geen 0day, Tweakers titel klopt niet echt.

[borft]

Mwah, ik vind het sterk overdreven. Als je webserver goed geconfigd is, kan je met een andere host header helemaal niet bij wordpress terecht komen. Ten tweede heb je als het goed is wp-admin en wp-login pagina's helemaal niet publiekelijk beschikbaar.

maw, een storm in een glas water.

[Reactie gewijzigd door borft op 24 juli 2024 12:55]

[aadje93]

niet iedere wordpress site is een single-user site . Denk aan community's of semi-forum blogs.

[xleeuwx]

Er zij heel veel grote bedrijven met meerdere logins, daarnaast staan daar ook de namen + e-mails van de personen vaak op de website

[WPbeveiligen]

Ithemes security pro zorgt ervoor dat je het admin naar een ander adres kunt verplaatsen.
Tevens blokkeerd die beveiliging diverse pogingen, lange en verdachte url's, standaard gebruikers etc.
Combineer dat met updraftplus voor de backups en je bent al een heel eind op weg naar een veilige website.

[Peran]

Er zitten best veel gaten in WordPress? Het staat me zo bij dat er jaarlijks problemen zijn de afgelopen 5 jaar. /opgevoel

[Reactie gewijzigd door Peran op 24 juli 2024 12:55]

[Bender]

Nee hoor, meeste problemen van Wordpress zitten tussen het toetsenbord en de bureaustoel.

Denk aan onveilige wachtwoorden, willekeurige plugins downloaden en installeren, die niet uitschakelen als je ze niet gebruikt of inderdaad Wordpress websites op PHP 5.0 die 7 jaar niet geupdate zijn.

[killercow]

Gelul.

Wordpress is een ontzettend slecht gebouwde php applicatie.
Php heeft al niet zo'n best track reccord omdat je vrij gemakkelijk fouten kunt maken die statischere talen moeilijker zijn. Dit speelt onhandige fouten in add-ons in de kaart.

Maar ook het wordpress dev team staat regelmatig met zn hakken in het zand als derden securityproblemen in wordpress van te voren willen oplossen en zelfs de code aandragen.

Maargoed, de gemiddelde wordpress installatie wordt dan ook beheerd door een tiener op een zolderkamer, en de gemiddelde wordpress klant zoekt specifiek die tiener, omdat het zo maar een paar honder euro kost om een website online te krijgen.

Security is moeilijk, software bouwen is moeilijk, en als je een platform gebruikt dat het makkelijk heeft gemaakt voor allerlei beginners om aan die code te zitten zonder dat daar security checks in zitten kan elke fout van een themaontwikkelaar (ongeveer iedereen die wordpress gebriukt, want het is zo makkelijk) of add-on ontwikkelaar een fout zijn die je hele platform onveilig maakt. Koppel aaraan de duizenden pagina's die 'problemen' oplossen door chmod777 voor te stellen, of een plugin introduceren om een meta-tag toe te voegen aan je pagina en ziet waar de onmogelijke securitysituatie vandaan komt.

Met de install-base van wordpress neemt de wordpress een verantwoordelijkheid op zich waar ze wel de vruchten van plukken maar security als bijkomend probleem zien wat later wel kan worden opgelost.

* https://web.archive.org/w...the-internet-298a7e5b6871
* http://chrislema.com/wordpress-security/

[geert1]

Er zit best wat waarheid in wat je zegt, maar de doelgroep waar jij het over hebt (sites van een paar honderd euro door een "tiener") is over 't algemeen weinig interessant voor hackers, en de schade zou erg beperkt zijn.

Sites met veel bezoekers of omzet (waar dus iets te halen valt qua geld of data, of de hacker veel aandacht kan trekken voor een ideologie bijv), daar wordt Wordpress meestal een stuk serieuzer gebruikt. Dan is de beveiliging op orde (o.a. met solide server-configuratie, IP white-listing voor de admins, enz), worden er geen twijfelachtige plugins gebruikt, zit het thema zorgvuldig in elkaar en zijn zaken als chmod777 uit den boze.

Dan zie je dat de problemen, zoals je deels zelf al zegt, meer het gevolg zijn van onjuist gebruik van Wordpress dan van Wordpress zelf. Er worden best eens beveiligingsproblemen gemeld in Wordpress, maar vaak zijn die met een solide configuratie al niet toe te passen (zo ook deze niet), en verder zijn het er niet duidelijk méér dan andere systemen met soortgelijk aantal installaties. Wordpress is een groot doelwit en zal dus meer aangevallen worden, net als Windows vs. MacOS bijvoorbeeld.

Door de lage instap en het imago van "Wordpress is voor iedereen", wordt verkeerd gebruik wel tot op zekere hoogte in de hand gewerkt. Maar zoals gezegd is onzorgvuldig gebruik vooral een probleem bij kleine websites die het hacken amper waard zijn. Er zijn vast ook belangrijke, waardevolle sites die het toch niet netjes voor elkaar hebben, maar dan geldt wat mij betreft: "wie geen geld wil uitgeven, mag op de blaren zitten als het misgaat".

Wordpress kan op zich prima gebruikt worden voor middelgrote webwinkels of landelijke blogs bijvoorbeeld, als er maar verantwoordelijk ontwikkeld wordt. En elk systeem kan kreupel gemaakt worden met de verkeerde ontwikkelaar erachter.

[Foamy]

Er zit best wat waarheid in wat je zegt, maar de doelgroep waar jij het over hebt (sites van een paar honderd euro door een "tiener") is over 't algemeen weinig interessant voor hackers, en de schade zou erg beperkt zijn.

Ik denk dat je je daarop verkijkt. Verreweg het meeste aantal WP sites dat wordt gehackt zijn juist de kleinere sites. Deze worden vervolgens gebruikt voor verzenden van spam, hosting van phising sites, etc.
Bron: mezelf, ik werk bij een hostingprovider en kom derhalve nog wel eens een gehackte site tegen.

[geert1]

Kleine sites worden inderdaad wel best vaak gehackt voor spam-doeleinden, maar daarbij geldt de strekking van mijn post nog steeds: wie een veilige site wil, moet verantwoordelijk (laten) ontwikkelen, en wie geen geld wil uitgeven die komt op de blaren te zitten. Wordpress zelf is daarbij niet het kernprobleem; ze zijn alleen een groot doelwit en eentje met relatief veel onkundige ontwikkelaars en gebruikers (die bijvoorbeeld een zwak wachtwoord kiezen).

Doen de ontwikkelaar, gebruiker en hoster wat ze horen te doen, dan is Wordpress niet onveiliger dan andere systemen. En doen ze dat niet, dan is geen enkel systeem veilig.

[WhatsappHack]

Ja als je in een utopie zit is er niets aan de hand dus Wordpress an sich is echter niet slecht, het probleem zit hem vrijwel altijd bij de gebruiker die te pas en te onpas rot plugins installeren (al behoort dat beter gescreened te worden) en wordpres eigenlijk gebruiken voor iets waar t nooit voor bedoeld was.
Daarnaast volgt niemand de stappen om wordpress te hardenen. En ja dan heb je ook nog rotte hosts die niet eens aan user isolation doen. Maar ook dat is niet de schuld van WordPress.

Face it, een kale wordpress blog? Die worden nauwelijks gehackt als ze up to date gehouden worden. Het zijn die gedrochten die met duizend plugins aan elkaar hangen om er een CMS van te maken die de pleuris doen uitbreken.

[Bender]

Ik ben het met je eens dat Wordpress niet het paradepaardje is van mooi gecode software.

Maar dat neemt niet weg dat wat ik aangeef zeker wel waar is, van alle gehackte Wordpress websites die ik ben tegengekomen (veel, fulltime werk) komt het tot nu toe altijd door plugins en hele oude Wordpress/PHP versies van 7 jaar of ouder.
Eigenlijk bevestig je het ook zelf dat het wel degelijk de gebruiker is met "beheerd door een tiener" en daar heb je ook gelijk in.
(maar ook hier, niet allemaal want genoeg corporate omgevingen waar het in gebruikt wordt)

[svennd]

Gelul.

Elke complexe applicatie die open-source gebouwd wordt is moeilijk te onderhouden, en wanneer je 25% of meer van het internet draait is iedere fout meteen een nieuwstopic.

PHP heeft geen slechte track record, net als WP is het gewoon populair. Dat PHP een eenvoudige taal is, maakt het uitermate geschikt voor beginners, dezelfde redenering geld voor Windows en Windows gebruikers.

Welke fantastische talen zijn volgens jouw dan wel beter ? Brainfuck ? TCL ? RoR ? Java ?

Dit soort exploits, zijn best mogelijk, maar om daarom heel de community te verwijten van tieners zonder enige verstand, komaan zeg.

[JoeyPrr]

https://medium.com/@photo...update-signing-51501213e1

Post dan ook meteen de reactie van Matt Mullenweg.

[TheWind]

Waar maar tegelijkertijd wordt het de gebruiker bij Wordpress ook wel heel gemakkelijk gemaakt om een lek te creëren. Begrijp me niet verkeerd, maar als developer zou ik niemand Wordpress aanraden.

Er zijn wel degelijk een aantal zaken die Wordpress veel kwetsbaarder maken

* Elke harry met een toetsenbord kan een plugin schrijven voor wordpress, omdat er veel tutorials/examples zijn. Betekent niet dat deze ook enige kennis hebben van beveiliging. Er zijn dus veel brakke plugins (ook betaalde) en er is geen goede manier om het kaf van het koren te scheiden. Zeker voor een leek die dus een simpele website wil. Elke thema/plugin vormt dus een risico. Zeker omdat de support van deze ophoudt bij de installatie. Betaalde plugins zijn misschien nog wel meer een risico omdat niemand de source kan beoordelen.

* Structuur(of juist de afwezigheid daarvan) is voor een groot oorzaak van deze lekken. Er is geen Request/Response abstractie, database abstractie laag is erg beperkt en wordt door weinig plugins gebruikt. Hierdoor wordt door veel developers direct gebruik gemaakt van input variablen zonder deze te valideren/filteren. Geen fatsoenlijke templating, maar brakke php code die een soort van layout samen raapt. Dit zorgt ervoor dat je gewoon erg kwetsbaar ben voor SQL injection, cross-site-scripting etc.

* Je kan niet aannemen dat de doorsnee leek weet wat een goede en een minder goede plugin is. Vroeg of laat zit er een keer een lek in je website

Als je dan toch de keuze hebt en een PHP cms nodig hebt, kies dan bijvoorbeeld:

https://octobercms.com/
https://www.drupal.org/
https://www.concrete5.org/

[blinchik]

Updates bij Drupal vind ik anders een pak moeilijker geregeld dan bij Wordpress. Wordpress updates, inclusief plugins, gaan volledig automatisch en bijna nooit mis.

[dimitrivisser]

Begrijp me niet verkeerd, maar als developer zou ik niemand Wordpress aanraden.

En jouw onderbouwing is "omdat er een hoop slechte programmeurs slechte plugins schrijven".

Als je met Wordpress goed let op de bestandsrechten en geen gekke plugings installeert dan is Wordpress net zo veilig als alle andere systemen.
Ik heb nog nooit een hack van Wordpress gezien veroorzaakt door iets anders dan 100% eigen schuld.

[poerkiemen]

Hoe is het security (beleid) van octobercms in vergelijking met die van wordpress beter en/of slechter?

[innerchild]

Daarom moet je je plugins ook altijd kopen. Dan heb je tenminste zekerheid op support. Kost geen drol om een plugin aan te schaffen voor wordpress indien je daar wat serieuzer in zit.

[Bender]

Helemaal mee eens, ik werk veel met premium plugins.
Het kost gewoon minder tijd om de juiste te vinden en het te laten werken, juist mijn eigen tijd is het duurste van alles.

[WhatsappHack]

Nou die zekerheid ligt ook maar net aan de ontwikkelaar helaas...

[DJMaze]

Er zijn ook zat plugins die men koopt die vol fouten zitten.
Ga jij dan in de support melden "ik ben gehackt"?

[twixx]

Of zijn er best veel gebruikers en is het daarom de moeite waard om ze te benoemen? Ik zou dat opgevoel vervangen door cijfers.

[Stoelpoot]

Tja, dat krijg je met een groot en volledig softwarepakket. Windows heeft elke maand een security patch en nog steeds blijven er problemen komen. Perfectie bestaat niet.

[Oid]

Altijd two factor er tussen, kost niets...
Los van de bugs in de code is dat al zeker een goed begin!

[Reactie gewijzigd door Oid op 24 juli 2024 12:55]

[WPbeveiligen]

Ieder jaar wordt WordPress doorontwikkeld en worden er nieuwe lekken gevonden door de duizenden hackers die het internet willen "veroveren" met hun reclame.

[Reactie gewijzigd door WPbeveiligen op 24 juli 2024 12:55]

[Peran]

Net zoals de meeste programma's?
Ik snap niet wat je bedoelt met deze reactie 3 weken na de vorige..

[Verwijderd]

Het is wel makkelijk om het zo op te lossen, of bijvoorbeeld als fallback voor een niet-ingesteld 'afzenderadres' ([e-mail] b.v.) is dit voor de gebruiker erg makkelijk.
Al zou het erg weinig moeite zijn tijdens de installatie hierom te vragen en het standaard instellen op het huidige domein is op dat moment wel prima.

Verder kan je natuurlijk even simpel gezegd het volgende stuk code bovenin je index.php plakken $_SERVER['HTTP_HOST'] == 'de juiste' OR die();

[edit]
Ik zie hier ook wel een mogelijkheid de VirtualHost te greppen per user en dan met sed e.d., alle juiste files van wordpress-installaties 'patchen' met de bovengenoemde manier...
Handig voor webbouwers die zelf vele klanten hosten misschien...

Maar misschien is UseCanonicalName DNS nog robuuster dan de in het artikel aangehaalde optie (minder foutgevoelig wellicht; VirtualHost is niet altijd de juiste, soms wordt een alias gebruikt)

[Reactie gewijzigd door Verwijderd op 24 juli 2024 12:55]

[Foamy]

Dit zal niet gaan helpen, aangezien de POST rechtstreeks gaat naar de inlogpagina van de site die je aan probeert te vallen:

POST /wp/wordpress/wp-login.php?action=lostpassword HTTP/1.1
Host: injected-attackers-mxserver.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 56

user_login=admin&redirect_to=&wp-submit=Get+New+Password

Je zou dat specifieke bestand dus moeten patchen hiervoor. Echter: dit zal bij de eerstvolgende update van WP weer ongedaan worden gemaakt, aangezien dan de bestanden weer worden overschreven. Beter gebruik je hiervoor een filter vanuit een plugin:

add_filter( 'wp_mail_from', function( $from_email ) { return '[e-mail]'; } );

[Reactie gewijzigd door Foamy op 24 juli 2024 12:55]

[Verwijderd]

Sorry, geen verstand van Wordpress
Inderdaad als niet alles via de index.php loopt, relevante bestand(en) zo patchen.

[Foamy]

Je hoeft niet ieder bestand te patchen

Het filter hierboven kun je in je thema of een plugin opnemen. Die doet het werk voor je

[Verwijderd]

Weer iets nuttigs geleerd, hehe.
[offtopic]
Het is handig źo'n filter maar je IDE volgt het totaal niet meer, en ik vind het zelf ook lastig te zien wat er nou allemaal gebeurd in zo'n Wordpress install als er her en der filters toegepast worden. Dat ligt natuurlijk ook vooral aan de bouwers van een website.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 12:55]

[Foamy]

Offtopic:
Dat zal er inderdaad mee te maken hebben op welke wijze een website is opgebouwd. Als een bouwer zn werk goed doet (en documenteerd) dan is alles goed terug te vinden, en kun je vrij goed afleiden wat wat nu doet in zo'n site.

[hackerhater]

hmmm als $_SERVER[' HTTP_HOST'] niet betrouwbaar is, zullen heel veel systemen op hun gat gaan!
Heel veel frameworks and CMS'en zullen deze variabele gebruiken om te detecteren op welk domein het systeem draait.

[m3nt0s]

Ze gaan er hier ook van uit de de server een bounce stuurt met de originele email als bijlage. Dit lijkt mij geen standaard gedrag van een mail server?

[Verwijderd]

Je hebt gelijk denk ik. Sowieso zet Exim standaard ook een original-from header als het domein niet in de permitted senders lijst zit.
Wat mij een goede optie lijkt is een whitelist opbouwen op basis van de aanwezige virtualhosts; Directadmin heeft zo'n lijst al bijvoorbeeld; die zou je zo kunnen inzetten als whitelist only. (/etc/virtual/domains )

[Reactie gewijzigd door Verwijderd op 24 juli 2024 12:55]

[Ventieldopje]

Ben ik nou stom of is dit héél héél makkelijk te fixen door WP? Het domein staat al in de options tabel, die wordt na de installatie al opgeslagen. Zometeen maar zelf een patch schrijven dan

Edit: Done. Testen = liev https://gist.github.com/m...d587d7cea50f5962fa7d0f290

[Reactie gewijzigd door Ventieldopje op 24 juli 2024 12:55]

[RJWvdH]

/wp-includes/pluggable.php
$_SERVER['HTTP_HOST'] == parse_url( network_home_url(), PHP_URL_HOST ) OR die();

Lijkt me voldoende en iets eenvoudiger als tijdelijke fix

[Reactie gewijzigd door RJWvdH op 24 juli 2024 12:55]

[Ventieldopje]

Behave dat je het helemaal in een if gooit, gewoon de waarde veranderen zoals in mijn patch is minder werk en dan heb je geen die in je code, wat een stuk beter is voor debuggen.

Zie overigens ook de discussie op hun trac

[Reactie gewijzigd door Ventieldopje op 24 juli 2024 12:55]

[NiGeLaToR]

En omdat inmiddels zo'n 25% (of inmiddels al meer) van de websites op Wordpress draait is dit voor kwaadwillende een zeer interessant onderwerp om zich op te storten.

Wat wel storend is, is dat dit fenomeen al gemeld is bij Wordpress, maar nog niet is opgepakt. Nu zie ik ook wel dat het geen exploit is die iedereen heel eenvoudig kan toepassen, maar aan de andere kant is het ook al een flinke tijd bekend.

[Reactie gewijzigd door NiGeLaToR op 24 juli 2024 12:55]

[dimitrivisser]

De hack is zuiver theoretisch en in de praktijk onbruikbaar.

"Als mogelijk scenario noemt Golunski het uitvoeren van een dos-aanval op het e-mailaccount van het slachtoffer, zodat de resetmail een bounce krijgt naar het domein van de aanvaller."

Dan moet je dus wel eerst al op de hoogte zijn van het emailadres van de gebruiker waar je het account van wil hacken. Dat vereist voorkennis. En daarnaast heb ik gmail. Ik wens ze veel succes met een dos aanval op google..

99,9% van de hacks op Wordpress websites heeft te maken met slechte plugins en foute bestandsrechten. Scriptkiddies proberen duizenden websites uit in de hoop er 1 te pakken te krijgen met een foutce configuratie. Meer zit er nooit achter. Ik heb nog nooit een hack gezien gericht op een bepaalde website specifiek met het doel om die ene website te hacken. Het kost teveel tijd voor een te geringe opbrengst.

[supersnathan94]

Ik ken genoeg bedrijven die [e-mail] gebruiken als wordpress admin adres.

[dimitrivisser]

Dat zijn diezelfde bedrijven die hun wordpress website hosten op dezelfde shared hostiing waar ook de email op aankomt.

Het platleggen van de emailserver zorgt dus ook voor het platleggen van de webhosting waardoor een password reset niet meer mogelijk is

Serieus, ik denk dat deze exploit een storm is in een glas water.

[bartje]

ik heb dit even in de praktijk getest,
en het probleem is dat ik binnen 2 minuten via postman een werkend voorbeeld heb.

[Erulezz]

Ik lees hier alleen over Apache, maar hoe zit met Nginx?

[Hr_Berto]

Dit werkt (in elk geval bij apache) dan alleen als je default host wordpress draait