Aanvallers stelen wachtwoorden via lek in MySQL-tool Adminer
Aanvallers maken misbruik van een beveiligingslek in Adminer, een populaire tool voor het beheren van MySQL- en PostgreSQL-databases, om wachtwoorden van webwinkels te stelen. Dat laat de Nederlandse beveiligingsonderzoeker Willem de Groot in een analyse weten.
Om de wachtwoorden te kunnen stelen moeten aanvallers een open Adminer-installatie van het slachtoffer verbinding met een kwaadaardige MySQL-server laten maken. "Dit is niet lastig, aangezien veel mensen het in de root van hun website installeren", aldus De Groot. Adminer maakt dan verbinding met de kwaadaardige servers. De aanvallers vragen Adminer om een specifiek bestand dat het wachtwoord van geïnstalleerde applicaties gaat. Het gaat dan bijvoorbeeld om webwinkels die op het Magento-platform zijn gebaseerd, of WordPress-websites.
De kwetsbaarheid zou al sinds augustus 2018 bekend zijn. De Groot laat weten dat de aanvalsmethode al op z'n minst sinds oktober 2018 door criminelen wordt gebruikt. Destijds had de onderzoeker nog niet door wat er precies plaatsvond. Wel zag hij dat criminelen het lek gebruikten om op verschillende grote webwinkels een skimmer te injecteren die creditcardgegevens van klanten opving en terugstuurde.
De Groot merkt op dat hij Adminer versie 4.3.1 tot en met 4.6.2 heeft getest en al deze versies zijn kwetsbaar. Adminer versie 4.6.3, die vorig jaar juni verscheen, blijkt niet kwetsbaar te zijn. "Het is onduidelijk of het beveiligingslek opzettelijk is verholpen of per ongeluk, aangezien Adminer geen beveiligingsupdate vermeld", aldus de onderzoeker. Beheerders krijgen het advies om naar de laatste versie (4.7.0) te upgraden en toegang tot de database via een extra wachtwoord of ip-filter te beschermen.
Reacties (8)
21-01-2019, 19:29 door
Krakatau
Adminer was voorheen phpmyadmin. Ze hebben de naam al aangepast om niet meer met dat hobbytaaltje geassocieerd te worden. Dat is helaas niet genoeg want het is nog steeds een in PHP geschreven tool. En dan weet je het wel, nietwaar?
21-01-2019, 20:18 door
Anoniem
"hobbytaaltje", alle programmeertalen zijn hobbytaaltjes, dat heeft verder niets met het artikel te maken.
Lekken komen in iedere programmeertaal voor, het is afhankelijk van de programmeur.
Lekken komen in iedere programmeertaal voor, het is afhankelijk van de programmeur.
21-01-2019, 21:04 door
Tha Cleaner
Door Krakatau: Adminer was voorheen phpmyadmin. Ze hebben de naam al aangepast om niet meer met dat hobbytaaltje geassocieerd te worden.
Zou er misschien ook mee te maken kunnen hebben, dat Adminer veel meer ondersteuning heeft voor andere databases? en phpmyadmin niet echt meer een juiste naam voor het product kan zijn?Dat is helaas niet genoeg want het is nog steeds een in PHP geschreven tool.
Dus? Mooie universe programmeertaal. Wordt best veel gebruik op internet mocht je dat nog niet door hebben. Oa Wikipedia is er in geschreven.En dan weet je het wel, nietwaar?
Nee eigenlijk niet. Uit eindelijk hangt het van de programmeur af, hoe de kwaliteit van de code is.
21-01-2019, 22:47 door
Anoniem
@Tha Cleaner,
Wat een misvatting dat er geen verschillen zouden bestaan in de syntax van een bepaalde taal.
Is babel niet beter als plain javascipt voor specifieke toepassingen.
Daarnaast telt ook de interactie met de omgeving.
Denk aan de specifieke DOM-XSS ellende met bijvoorbeeld bootstrap.js en min.js etc.
Ook het voortduren van deze kwestbaarheden, nadat het ontwerpersteam het doortrok naar de volgende versie 3.0.4
Zie: https://snyk.io/vuln/npm:bootstrap:20180529 -
Gecompromitteerde websites kunnen vaak gelinkt worden met kwaadaardig script & het kan reeds fout gaan bij niet juist toepassen van installatiescripts.
Voorbeeldje af te voeren bibliotheek -> http://turkeytoday.org/media/jui/js/jquery.min.js?939b0ef64cfbe0ecf88c0a66e2818945
jQuery versions with known weaknesses
Bug 9521 - $("#<img src=x onerror=...>")
Bug 11290 - $("element[attribute='<img src=x onerror=...>'")
jQuery issue 2432 - 3rd party $.get() auto executes if content type is text/javascript
jQuery issue 11974 - parseHTML executes inline scripts like event handlers (uit de dagen van pre-HTML javascript).
Bij gepatchte code en niet toegevoegde extra hardening door middel van extra security maatregelen,
moet het sein veilig altijd nog weer getoetst worden.
Daar doen mindere en beter coderende developers helaas niets aan af en toe.
Brendan Eich bijvoorbeeld heeft zelf toegegeven, wat persistente ad-tracking van grote Big Tech Data Miners allemaal al voor ellende t.a.v. JavaScript heeft gebracht. Niet iedereen is er van op de hoogte dat zelfs het pre-loaden van webpagina's niet volgens de regels gebeurt, maar om Google chrome beter af te schilderen tegenover andere browsers.
Tot het moment dat zulk soort zaken openbaar worden aangekaart, gaan men ermee door.
Men past zich steeds aan als een kameleon. Nu gaan de pagina's pas te zien zijn als ze geheel geladen zijn.
Niet hoog tijd om het eens gezamenlijk structureel en fundamenteel aan de tand te voelen,
en dan "call a spade a spade". Waarom gebeurt dat dan maar zo mondjesmaat.
luntrus
Wat een misvatting dat er geen verschillen zouden bestaan in de syntax van een bepaalde taal.
Is babel niet beter als plain javascipt voor specifieke toepassingen.
Daarnaast telt ook de interactie met de omgeving.
Denk aan de specifieke DOM-XSS ellende met bijvoorbeeld bootstrap.js en min.js etc.
Ook het voortduren van deze kwestbaarheden, nadat het ontwerpersteam het doortrok naar de volgende versie 3.0.4
Zie: https://snyk.io/vuln/npm:bootstrap:20180529 -
Gecompromitteerde websites kunnen vaak gelinkt worden met kwaadaardig script & het kan reeds fout gaan bij niet juist toepassen van installatiescripts.
Voorbeeldje af te voeren bibliotheek -> http://turkeytoday.org/media/jui/js/jquery.min.js?939b0ef64cfbe0ecf88c0a66e2818945
jQuery versions with known weaknesses
Bug 9521 - $("#<img src=x onerror=...>")
Bug 11290 - $("element[attribute='<img src=x onerror=...>'")
jQuery issue 2432 - 3rd party $.get() auto executes if content type is text/javascript
jQuery issue 11974 - parseHTML executes inline scripts like event handlers (uit de dagen van pre-HTML javascript).
Bij gepatchte code en niet toegevoegde extra hardening door middel van extra security maatregelen,
moet het sein veilig altijd nog weer getoetst worden.
Daar doen mindere en beter coderende developers helaas niets aan af en toe.
Brendan Eich bijvoorbeeld heeft zelf toegegeven, wat persistente ad-tracking van grote Big Tech Data Miners allemaal al voor ellende t.a.v. JavaScript heeft gebracht. Niet iedereen is er van op de hoogte dat zelfs het pre-loaden van webpagina's niet volgens de regels gebeurt, maar om Google chrome beter af te schilderen tegenover andere browsers.
Tot het moment dat zulk soort zaken openbaar worden aangekaart, gaan men ermee door.
Men past zich steeds aan als een kameleon. Nu gaan de pagina's pas te zien zijn als ze geheel geladen zijn.
Niet hoog tijd om het eens gezamenlijk structureel en fundamenteel aan de tand te voelen,
en dan "call a spade a spade". Waarom gebeurt dat dan maar zo mondjesmaat.
luntrus
22-01-2019, 16:19 door
Anoniem
Tijd om je Magento 1 of 2 CMS hier te testen: https://www.magereport.com/
Aanvaller moeten eerst een kwetsbare "open" adminer.php zien te vinden.
Fluitje van een cent via een shodannetje etc.
Opnieuw php, nu rond lekkende wachtwoorden. Het houdt maar niet op.
# sockpupet
Aanvaller moeten eerst een kwetsbare "open" adminer.php zien te vinden.
Fluitje van een cent via een shodannetje etc.
Opnieuw php, nu rond lekkende wachtwoorden. Het houdt maar niet op.
# sockpupet
23-01-2019, 09:24 door
Power2All
PHP een hobby taaltje noemen is wel zeer een belediging voor velen.
Het is een prima taal om code zoals een website in te schrijven.
PHP 7.4 zal zelfs Java onder druk zetten (nee, niet javascript).
JavaScript was ook als een hobby taaltje begonnen door een enkele persoon, wat nu uitgegroeid is tot een volwaardige taal, zie NodeJS wat veel sprongen gemaakt heeft.
Zelf ben ik een voorstander voor PHP, Python (PyPy vanwege doei doei GIL of Cython) en C++.
Voor de rest, Java is een draak van een programmeer omgeving, veel resources nodig wat veelvuldig vaak niet nodig is.
Anyway, Symfony/Laravel is zeer populair de laatste tijd onder web and API programmeurs, dus ik zie het probleem niet.
phpMyAdmin nooit meer gebruikt sinds ik via MySQL command line alles kan doen.
Daarnaast, werkt HeidiSQL ook prima, via een VPN connecten naar de server, en de rest firewallen, klaar...
Het is een prima taal om code zoals een website in te schrijven.
PHP 7.4 zal zelfs Java onder druk zetten (nee, niet javascript).
JavaScript was ook als een hobby taaltje begonnen door een enkele persoon, wat nu uitgegroeid is tot een volwaardige taal, zie NodeJS wat veel sprongen gemaakt heeft.
Zelf ben ik een voorstander voor PHP, Python (PyPy vanwege doei doei GIL of Cython) en C++.
Voor de rest, Java is een draak van een programmeer omgeving, veel resources nodig wat veelvuldig vaak niet nodig is.
Anyway, Symfony/Laravel is zeer populair de laatste tijd onder web and API programmeurs, dus ik zie het probleem niet.
phpMyAdmin nooit meer gebruikt sinds ik via MySQL command line alles kan doen.
Daarnaast, werkt HeidiSQL ook prima, via een VPN connecten naar de server, en de rest firewallen, klaar...
23-01-2019, 19:20 door
Anoniem
Hoi, Power2All
Maar met het blootleggen van kwetsbaarheden op een website CMS moet je wel blijvend doorspitten.
Vergelijk de algemene scan hier https://retire.insecurity.today/#!/scan/b2730c739adb8993201689359cdf96726cabc4186695df06b2bfc6221a3494d7
met de scan voor jquery.min.js/JSTag_1[c8fd][b28e] ,die we aanvankelijk niet hebben meegenomen.
Vervolgens blijkt die ook kwetsbaar, zie:
https://retire.insecurity.today/#!/scan/7187586fc2d44df7e5693019bd9efadbcd8530630d21e8eec7986cfba644e704
Vooral php-gebaseerd CMS (Magento, Word Press, Joomla) in de handen van degenen, die code-security niet voldoende op het netvlies hebben, alsmede het toepassen van een verhoogde beveiligingsgraad door het toepassen van zogeheten "best policies" vaak achterwege laten.
Dan hebben we het nog niet eens gehad in het bovenstaande geval over de DOM-XSS sources & sinks in de gebruikte script en bibliotheken, respectievelijk voor de onderhavige 41 sources en 17 sinks. Die leveren stuk voor stuk natuurlijk niet allemaal een toepasbare exploit/bug op, maar desalniettemin. Ik zie er te weinig oog voor en ik zie het ,vooral bij amateurs, teveel ellende opleveren.
In hoeverre php-code op zich inherent onveilig is blijft natuurlijk onderwerp van discussie. Af te voeren PHP code vormt altijd een risico, maar soms zit je met verplicht backporten. Met het voortdurend moeten checken van de code op bijvoorbeeld een
#sockpuppet
Maar met het blootleggen van kwetsbaarheden op een website CMS moet je wel blijvend doorspitten.
Vergelijk de algemene scan hier https://retire.insecurity.today/#!/scan/b2730c739adb8993201689359cdf96726cabc4186695df06b2bfc6221a3494d7
met de scan voor jquery.min.js/JSTag_1[c8fd][b28e] ,die we aanvankelijk niet hebben meegenomen.
Vervolgens blijkt die ook kwetsbaar, zie:
https://retire.insecurity.today/#!/scan/7187586fc2d44df7e5693019bd9efadbcd8530630d21e8eec7986cfba644e704
Vooral php-gebaseerd CMS (Magento, Word Press, Joomla) in de handen van degenen, die code-security niet voldoende op het netvlies hebben, alsmede het toepassen van een verhoogde beveiligingsgraad door het toepassen van zogeheten "best policies" vaak achterwege laten.
Dan hebben we het nog niet eens gehad in het bovenstaande geval over de DOM-XSS sources & sinks in de gebruikte script en bibliotheken, respectievelijk voor de onderhavige 41 sources en 17 sinks. Die leveren stuk voor stuk natuurlijk niet allemaal een toepasbare exploit/bug op, maar desalniettemin. Ik zie er te weinig oog voor en ik zie het ,vooral bij amateurs, teveel ellende opleveren.
In hoeverre php-code op zich inherent onveilig is blijft natuurlijk onderwerp van discussie. Af te voeren PHP code vormt altijd een risico, maar soms zit je met verplicht backporten. Met het voortdurend moeten checken van de code op bijvoorbeeld een
;
die ergens achterwege is gebleven, heeft onze vriend Krakatau wel een punt. Alhoewel zijn algemene kwalificering populariserend blijft in mijn ogen. Maar waar blijft, dat php-gerelateerde CMS in handen van hobbyisten heel veel ellende aan kan richten, net zoals gratis websoftware bij een cloud-abonnement bijvoorbeeld. #sockpuppet
28-01-2019, 11:06 door
Krakatau
Door Tha Cleaner:
Door Krakatau: Adminer was voorheen phpmyadmin. Ze hebben de naam al aangepast om niet meer met dat hobbytaaltje geassocieerd te worden.
Zou er misschien ook mee te maken kunnen hebben, dat Adminer veel meer ondersteuning heeft voor andere databases? en phpmyadmin niet echt meer een juiste naam voor het product kan zijn?phpAdminer zou het in dat geval heten. Ik denk dat ze twee vliegen in een klap hebben geslagen en meteen hebben onderschoffeld dat het tooltje in PHP is geschreven.
Door Tha Cleaner:
Dat is helaas niet genoeg want het is nog steeds een in PHP geschreven tool.
Dus? Mooie universe programmeertaal. Wordt best veel gebruik op internet mocht je dat nog niet door hebben. Oa Wikipedia is er in geschreven.Een 'mooie universe programmeertaal'? Weet je eigenlijk wel wat je schrijft? Natuurlijk wordt PHP veel gebruikt want het is goedkoop. De resulterende technical debt van al dat PHP-gebruik is voor ons allemaal een groot probleem.
Door Tha Cleaner:
En dan weet je het wel, nietwaar?
Nee eigenlijk niet. Uit eindelijk hangt het van de programmeur af, hoe de kwaliteit van de code is.Die misvatting is wijdverbreid. De programmeur heeft natuurlijk invloed, echter als je het echt wilt verklooien moet je de verkeerde programmeertaal gebruiken. Of erger nog, een taaltje dat helemaal niet is bedoeld voor serieus werk in professionele toepassingen. Omdat het goedkoop is en omdat jij de technical debt toch niet zelf hoeft op te lossen.
Door Anoniem: In hoeverre php-code op zich inherent onveilig is blijft natuurlijk onderwerp van discussie. Af te voeren PHP code vormt altijd een risico, maar soms zit je met verplicht backporten. Met het voortdurend moeten checken van de code op bijvoorbeeld een
#sockpuppet
;
die ergens achterwege is gebleven, heeft onze vriend Krakatau wel een punt. Alhoewel zijn algemene kwalificering populariserend blijft in mijn ogen. Maar waar blijft, dat php-gerelateerde CMS in handen van hobbyisten heel veel ellende aan kan richten, net zoals gratis websoftware bij een cloud-abonnement bijvoorbeeld. #sockpuppet
Ik denk dat je 'polariserend' bedoelt. Want ik wil zeker niet PHP populariseren. Voor de rest ben ik het met je eens. #sockpuppet ;-)
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.